Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by manish.earth):

 This looks pretty good! I like how you've set up the testing code.

 Some review comments

 > `const int _LOG_WARN = LOG_WARN;`

 This is interesting. Usually I'd just mirror the constants and leave
 comments, and bindgen is useful for automirroring (but y'all aren't using
 bindgen and that's ok).

 I guess this works. I've never seen constants mirrored this way but I do
 feel it is more resilient to code changing.

 {{{#!rust
 /// Allow for default cases in case Rust and C log types get out of
 sync
 #[allow(unreachable_patterns)]
 pub unsafe fn translate_severity(severity: LogSeverity) -> c_int {
 match severity {
 LogSeverity::Warn => _LOG_WARN,
 LogSeverity::Notice => _LOG_NOTICE,
 _ => _LOG_NOTICE,
 }
 }
 }}}



 There's no need for that `unreachable_patterns`. The only way stuff will
 go out of sync is if `LogSeverity` gets a variant added, however that will
 trigger a compiler error in this match (if you leave off the `_` branch).
 It's nice to be able to modify enums and immediately have the compiler
 tell you where you need to update things


 {{{#!rust
 unsafe {
 tor_log_string(translate_severity($severity),
 translate_domain($domain),
 func_ptr, msg_ptr
 )
 }
 }}}

 These will fail to resolve if called outside of the correct module with
 the right imports.

 The best thing to do is to use `$crate::tor_log_string(..)` (see the docs
 on `$crate`, https://doc.rust-lang.org/1.7.0/book/macros.html#the-
 variable-crate) which will ensure these will resolve wherever you use
 them.


 > `const ERR_LOG_MSG: &'static str`

 Rust lets you omit the `'static` now (this is recent, so it works on the
 latest stable but may not work on the compiler you're using)

 -

 One concern of mine is that the `tor_log_msg` macro contains unsafe code,
 and more problematically, it contains macro variables in that unsafe code.

 Now this is firmly in "why would anyone even _do_ that" territory, but for
 example someone could call `tor_log_msg!({some code}, )`, and that
 code would be expanded to be inside an unsafe block without the caller
 ever having to use unsafe.

 You should probably have severity/domain get bound to variables outside of
 the unsafe block.

 Ideally the entire macro body would be moved to a function, making the
 body just handle the `format!` stuff and calling the function. However,
 this means you can no longer do the testing trick where the test function
 itself returns what was printed.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Ok, see the merge request on gitlab here:
 https://oniongit.eu/network/tor/merge_requests/7

 This PR creates a minimal implementation for Rust modules to log using
 tor's existing logger.

 One issue that I ran into is that log levels/domains are defined as macros
 in C. I redeclared a small subset of these as constants- if this is the
 approach that we want to take, I can fill out the remainder of necessary
 constants. Another alternative is to define log level/log domain macros as
 constants in C.

 In order to run module-level Rust tests without linking to C, it is
 necessary to "stub" out direct calls to C functions. This PR adds a
 "testing" feature in order to optionally compile no-op implementations for
 testing. (The approach of "write C integration tests and test Rust in
 isolation" is an approach taken by Servo, although it would be great to
 get Rust people's eyes on this to double check how I've done this).

 Looking forward to feedback and suggestions how to improve!

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by chelseakomlo):

 * status:  assigned => needs_review
 * cc: isis (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] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport   |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by Hello71):

 * sponsor:  Sponsor8-can =>


Comment:

 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor8 says
 it is Android, but this change affects only nodes with many channels open,
 mainly participating nodes (relays, directories, etc). clients are
 unlikely to have this type of load, and mobile clients especially so.

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

Re: [tor-bugs] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport   |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by Hello71):

 I think that would be correct if all callers ensure that either side
 channels are (effectively) unobservable, such as in these background
 tasks, or that the foreign party has proved that it owns the private key
 for this public key. the former doesn't apply everywhere, and the latter
 sounds nearly impossible to ensure.

 tl;dr lgtm, ignore part about ed25519_pubkey_eq in previous comment

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

Re: [tor-bugs] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport   |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by Hello71):

 lgtm. (I wonder if ed25519_pubkey_eq could safely use fast_memcmp...
 although it doesn't really matter here)

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

Re: [tor-bugs] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport   |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * keywords:  tor-channel, tor-sched, 032-backport, review-group-25, review-
 group-26 => tor-channel, tor-sched, 032-backport
 * status:  needs_review => merge_ready


Comment:

 I think this is ready to merge, if you agree with the changes.

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

Re: [tor-bugs] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

[Tor Bug Tracker & Wiki]

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport, review-group-25, review- |
  group-26   |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 Hi, and sorry about the delay!

 I've fixed a few things I noticed in a new branch, `bug24119`, in my
 public repository (https://git.torproject.org/nickm/tor.git).  How does
 this look to you?

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25, review-group-26   |
Parent ID:  #23100   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 I added the comment and the consts in
 7ecc6ebcc2d58fd49ece7a4478a5b0eee0a97c37.

 I don't think that bending over backwards to propagate first_hop_succeded
 is an improvement. The variable is basically an alias for the first cpath
 being STATE_OPENED. This serves as a clarifying comment rather than than
 an optimization or abstraction. Trying to propagate the result a long way
 will be both less clear and more error prone, and doesn't save us anything
 that the compiler wouldn't optimize anyway.

 Nick has previously said that he prefers to squash things himself, so I'm
 just going to leave mikeperry/bug23114 unsquashed for now until we hear
 from him. That way he can also decide if he wants the refactoring commit
 (90b29f1cc56a2402d00373043748eb198815d9a4) to be squashed into Bug #23100
 or kept separate in the final merge.

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

Re: [tor-bugs] #24467 [Core Tor/Tor]: Enable -Wnormalized=nfkc when available to avoid source code identifier confusion

[Tor Bug Tracker & Wiki]

#24467: Enable -Wnormalized=nfkc when available to avoid source code identifier
confusion
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged 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] #22907 [Core Tor/Tor]: Investigate using cargo-vendor for offline dependencies

[Tor Bug Tracker & Wiki]

#22907: Investigate using cargo-vendor for offline dependencies
-+-
 Reporter:  isis |  Owner:  isis
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, tor-build, |  Actual Points:
  032-unreached  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-
Changes (by isis):

 * status:  accepted => needs_review


Comment:

 Okay, there's some better documentation and some Travis CI builds for
 cargo in offline-mode in my `bug22907`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug22907 branch].
 Hopefully this satisfies some of what's needed for #22768?

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

Re: [tor-bugs] #20020 [Core Tor/Tor]: Strange Warning: "Couldn't add re-parsed router: Some certs on this router are expired."

[Tor Bug Tracker & Wiki]

#20020: Strange Warning: "Couldn't add re-parsed router: Some certs on this 
router
are expired."
-+-
 Reporter:  torland  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop220-fallout, usability,  |  Actual Points:
  logging, relay, review-group-26|
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged 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] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 > Does the new arithmetic pass --fragile-hardening on x86_64 and i386?

 It does for me on x86_64.

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

Re: [tor-bugs] #24050 [Core Tor/Tor]: We still do client-side caching. We just don't use the cache.

[Tor Bug Tracker & Wiki]

#24050: We still do client-side caching. We just don't use the cache.
+--
 Reporter:  arma|  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  032-backport, ???-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+--
Changes (by nickm):

 * keywords:  032-backport, ???-backport, review-group-26 => 032-backport,
 ???-backport


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

Re: [tor-bugs] #17933 [Applications/Tor Browser]: Tor Browser does not isolate the pdf 'download' (via the download button) to URL bar domain

[Tor Bug Tracker & Wiki]

#17933: Tor Browser does not isolate the pdf 'download' (via the download 
button)
to URL bar domain
+---
 Reporter:  arma|  Owner:  pospeselr
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-usability  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by pospeselr):

 With latest ( tor-browser-52.5.1esr-7.5-1 ) when navigating to a pdf it
 looks like tor button is using the --unknown-- domain circuit for the
 first access, and then the correct domain circuit for subsequent ones.
 Creating a new circuit seems to reset this behaviour.

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

Re: [tor-bugs] #24474 [Internal Services/Tor Sysadmin Team]: Discontinue email forwarding for linda@

[Tor Bug Tracker & Wiki]

#24474: Discontinue email forwarding for linda@
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:
 |  needs_information
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

 * status:  new => needs_information


Comment:

 This is pending #24473.

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

Re: [tor-bugs] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+---
 Reporter:  ewyatt|  Owner:  atagar
 Type:  task  | Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 No problem. I was just checking our policy and we didn't really cover what
 happens with resignations. I'd expect it would require another vote to be
 triggered but happy for folks to discuss.

 
https://gitweb.torproject.org/community/policies.git/tree/community_council.txt#n65

 Since there hasn't been any announcements regarding Linda besides her TPI
 discontinuation officially speaking she's still on the council and a
 member. To conclude her council membership we need to figure out how
 that's handled (vote, or whatever). As for the later I need an official
 community council decision saying Linda is no longer a member for this and
 #24474.

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

Re: [tor-bugs] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+---
 Reporter:  ewyatt|  Owner:  atagar
 Type:  task  | Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by ewyatt):

 Replying to [comment:2 atagar]:
 > Hi Erin. Happy to, but we'd need either of two things...
 >
 > * For Linda's community membership to conclude.
 > * For Linda herself to request to be removed.
 >
 > There hasn't been any announcement saying she's not still a member of
 the council, and presently still on tor-internal@.

 Ok, no prob. I know she notified the CC, so I'll have one of them confirm.
 Thanks!

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

[tor-bugs] #24474 [Internal Services/Tor Sysadmin Team]: Discontinue email forwarding for linda@

[Tor Bug Tracker & Wiki]

#24474: Discontinue email forwarding for linda@
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please discontinue/remove email forwarding for linda@. She is no longer
 employed by TPI and does not want to continue working with the CC.

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlofMzAACgkQugyUAPgP
 kc6HYw/7BpC3W4ROYyT/HW2/arHYskc84Xz7gpFwGJ/XFOHKz+Bv1lVyUck/Uft/
 VT1DI2DJ7S4H/SGFErSfMemymoUYakAnQIUneJ7mG1tlOVXFVqwWxRY8Cnn998Pm
 pyTEt+jqz6pB8etn19oH7u6CPTUGD7aFjQQ3SpWI3UaspugS8rS7o6SgeoiPIWfx
 HfK1g+gb410ZTy3famF2WkChJB/j5vrHc6Y+gAMdLhSY+VwDvY42NOwFEQQaLk2d
 A9UIbSGV3O4SXP3Qb6ImJcQLRhkPu7QvYUlOqfIGcdVCfyeGwqBuBRahixjZu+vP
 ic7vbwHx2+pUbp82Bh3b3nvjO8mV0QocVDykb5MWBav4no70OFDh+4AVn5AJFaym
 35Z7851xvcMUSfsYq2JqyXynzFec6W8CCcNwO7hxT6AGt+3arujrNi/LNAJUmFKS
 mH+4SXPUROnFMquDbHFwAmcfPNeA57v4GtFZcbg1KGVjyZ2vOoV7aaCUswiMUuC1
 feZY+FkJ1O0uJb41j+V1q8Qfvi89xOH9cuJMyJCa6PsbgyYZ14JL1tY6uT8aDiDW
 I+OvL+gn/dlX5aT3+98gh3bIDEctdf0omUogcZQ1QQB6729+ZPa3TG/8ckmye+Q5
 ITMNm83sv3ehZyAeFqb4RELOS83jxvuhsP7qw4Rbanl6imQVv6Y=
 =ijRf
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+---
 Reporter:  ewyatt|  Owner:  atagar
 Type:  task  | Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  assigned => needs_information


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

Re: [tor-bugs] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+--
 Reporter:  ewyatt|  Owner:  atagar
 Type:  task  | Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

 * owner:  hiro => atagar


Comment:

 Hi Erin. Happy to, but we'd need either of two things...

 * For Linda's community membership to conclude.
 * For Linda herself to request to be removed.

 There hasn't been any announcement saying she's not still a member of the
 council, and presently still on tor-internal@.

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

Re: [tor-bugs] #24472 [Webpages/Website]: Please deactivate job posting on website (Browser Developers for Mobile)

[Tor Bug Tracker & Wiki]

#24472: Please deactivate job posting on website (Browser Developers for Mobile)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ewyatt):

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


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

Re: [tor-bugs] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ewyatt):

 * owner:  (none) => hiro


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+--
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512



 Please remove Linda’s listing on the people page. She is no longer
 employed by TPI and does not want to continue working with the CC for the
 time being.

 https://www.torproject.org/about/corepeople.html.en#linda

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlofMHgACgkQugyUAPgP
 kc7f3RAAgpYMc+aSJgYERQjM+dt7fbpkBGF2CM6qv2jLtBHx4gLb0k5bj9EPo2ZD
 65tPQ2zFqAwKwGL/NcA3qAGF8pdxzV0yzrKxHqijBL02jIebanOlkK122d2T2h4w
 2vsUGB6e3YQN08k5jqA91J9j2w815lxITHoH7m6+Zz2hbFDJAsUa3gG5x1nr785n
 Jvkf0D0kExm4Fe0TfmQ3B1x07SU6JegFWkTW+jRQHoGkmet48iohyN2pBGE3qQKX
 LU3x1GXzd1ZAGLX1xtDumcT+0Kow1D5A80A9Fh9yGXiwGqSTC8gsXFiK4EE77rGi
 yw23VMPxXF2vBDgxfqx/PWLhagPXz6WD4fbLqMbUy5YAiMiqyiXdMLPU/DzPYyYa
 +Ny8dgzuey2SM5I82YQRqcu9l7ZsCoV0C/NU7H6kMtgh+fnWoGOUscub8pNJRtk9
 llHJMMfEIs8cBTZ3TdGje6pE6155+TwXWS9NKP39JYxgFffOesxLduWj4qOrF3w9
 WuhHG+O6McIB1hVJdB8jOdOenWXJV7SKzqBrdvCxEMHJdZZ5/tNz8bSziOIjiz7q
 GhbHWo/cSXNbVbzOPuCtOx75+F5J53leOa1IF7LNeU+O1spdgX6P+WP2vucyhXSy
 l2jTy5usVIa1XeJSnefAnP14bWPooRTnlk8Gg6IjSR6j4Igs6Zs=
 =Po0t
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24472 [Webpages/Website]: Please deactivate job posting on website (Browser Developers for Mobile)

[Tor Bug Tracker & Wiki]

#24472: Please deactivate job posting on website (Browser Developers for Mobile)
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512



 Please deactivate the Browser Developers for Mobile (Android) job posting.
 Thank you!

 https://www.torproject.org/about/jobs-developerandroid.html.en

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlofLTAACgkQugyUAPgP
 kc6dgQ//Wf5KisJCdwiHDuqT8LRoK8BloyDVhs5yNswxODl4ZJRukhdkAPP/BvrV
 wbU/lTdCeVNxu4cFIF0ZQN/OAURdEHfc3iUA2iIpKzftfML/RgZe7FtES4d6oL9B
 122Y0XJuTR0sq2XXQNeR4rIlHLC+EELfhOZ4lsdfG0ZJHwp9OmcZGySO1alSKy9d
 BgHWzDFih+tK/VhSR92SLNnzBE/oxE3bq0Hi5GXNZxbDkuOfhFU1TE02UbCdW8IE
 YOArDL6QnnoZC9whC7qdsg18JARPJVvYi+IaU+JqMHKu/addnANJQcr2BUUEk+5h
 p96ZSU6dsSFHZbfrFUps88f24Fh0dRvQ9km62fciPBXW0MHmHyD4YYIupy7oSCGz
 z5gZMybW11KDdH2TI2AJ0Q6P5GTAoyCAbsXdv8O9QXOKzwc/eYGHjrCbZpDNosfC
 mgYO0zmjzzj6NkdFj6rYwhh3i7czZrc9FHROXnnEBvnJGtBJbA3sPEZbrjPKKPQq
 s8zrPRAyGGoHD7sX5ehyDxX2/KhM4+8zni0w9dwqn9MubhZLnIdapE1QqLl59Y4x
 f7EuCQKGwp36RxIzbuANfuDiMnZVRunoi9wbQkSWf4y99L6FWrEHgT7HrB88TKGx
 oPcIbFEhyt/ajvZxPNTQq574AGhmuh0FQm8Kbr1/+m5mzDMSgwA=
 =peku
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #17254 [Core Tor/Tor]: Scalable HSes by splitting intro/rendezvous

[Tor Bug Tracker & Wiki]

#17254: Scalable HSes by splitting intro/rendezvous
--+--
 Reporter:  TvdW  |  Owner:  TvdW
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs multicore scaling  |  Actual Points:
Parent ID:  #15251| Points:  6
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:   => #15251


Comment:

 This might help with #15251

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

Re: [tor-bugs] #15251 [Core Tor/Tor]: Make tor support starting with 10.000 Tor Hidden Service

[Tor Bug Tracker & Wiki]

#15251: Make tor support starting with 10.000 Tor Hidden Service
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, scalability, tor-dos  |  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by teor):

 You will probably need to fix the performance issues in #22210.
 You might also need something like OnionBalance, or more likely,
 rendezvous handoff from #17254.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+---
Changes (by mcs):

 * cc: isabela, antonela, tbb-team (added)
 * status:  new => needs_information


Comment:

 Kathy and I encountered some issues while implementing the Moat UI that is
 spec'd here:
  https://marvelapp.com/3f6102d/screen/31456318

 Here is the result when we try to place this design in the setup wizard:

 [[Image(moat-1-spec.png)]]

 Notice that the proxy settings are not close to fitting within what is
 already a fairly large dialog box. We could make the captcha image a lot
 smaller, but then it will be even more difficult to solve.

 Next, we experimented with a horizontal layout:

 [[Image(moat-2-horizontal.png)]]

 This is better in terms of space used, although the proxy settings still
 do not fit well. And the horizontal layout is awkward from a UX
 perspective (e.g., the text input box is to the right of the image instead
 of below). We also made the captcha image half size and you can see that
 it becomes challenging to decipher.

 While working on this, we also realized that there are a number of
 interaction problems with the current design:
 * What do we do after a bridge is received via moat? The obvious answer is
 that the bridge configuration line will show up in the "Provide a bridge I
 know" text area. But that means that having a radio button for the moat
 interaction does not make a lot of sense; it is a short-lived modal
 interaction (stop what you are doing, interact with BridgeDB, done) rather
 than a state that needs to be maintained.
 * There needs to be a way to cancel the moat interaction. Within the
 existing design that could be done by choosing a different radio button,
 but we may want to provide a more obvious way to cancel.
 * There should be a Submit button (pressing Return/Enter should also work
 of course).
 * There should be a way to request a different captcha image; we need a
 "reload" button.

 All of this led us to mock up a new design, and we would like everyone's
 input (especially the UX team's). Here is our proposed configuration
 screen:

 [[Image(moat-3a-proposed.png)]]

 Next, after the user clicks "Get a Bridge For Me" button, an overlay is
 used for the Moat interaction:

 [[Image(moat-3b-proposed.png)]]

 Is this a good direction to pursue? Kathy and I like it and think it
 solves the problems inherent in the original design, but we are also open
 to other ideas.

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

Re: [tor-bugs] #24467 [Core Tor/Tor]: Enable -Wnormalized=nfkc when available to avoid source code identifier confusion

[Tor Bug Tracker & Wiki]

#24467: Enable -Wnormalized=nfkc when available to avoid source code identifier
confusion
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks fine to me, let's get this merged.
 We could even put it in 0.3.2 if you want, nickm, but given how unlikely
 it is that someone will submit Unicode identifiers in a patch, master
 should be fine.

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

Re: [tor-bugs] #24471 [Internal Services/Service - jenkins]: Stem jenkins tests unable to invoke tor

[Tor Bug Tracker & Wiki]

#24471: Stem jenkins tests unable to invoke tor
-+
 Reporter:  atagar   |  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 Fixed.  We were missing two libs in the chroots that new tors link
 against.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-3a-proposed.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-3b-proposed.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-2-horizontal.png" removed.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-2-horizontal.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-1-spec.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-3b-proposed.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-2-horizontal.png" added.


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201711   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * Attachment "moat-1-spec.png" added.


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

Re: [tor-bugs] #24360 [Core Tor/Nyx]: When I open nyx and then Immediately click "qq" it will get in a state where nix disappears

[Tor Bug Tracker & Wiki]

#24360: When I open nyx and then Immediately click "qq" it will get in a state
where nix disappears
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by atagar):

 Hmmm, frustrating. Looked into our code for a while but unfortunately this
 doesn't provide much information about where the deadlock might be
 happening. If you ctrl+c does it provide anything? How reliably does it
 freeze for you and are you sure this is specific to during startup or does
 it happen other times 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] #24382 [Core Tor/Nyx]: I resized my terminal window and nyx crashed.

[Tor Bug Tracker & Wiki]

#24382: I resized my terminal window and nyx crashed.
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Major  | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks Dbryrtfbcbhgf! Another great catch. I can't reliably repro fix but
 pushed a fix that should address it...

 https://gitweb.torproject.org/nyx.git/commit/?id=c0276f9

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pospeselr):

 I realize we might be a bit constrained by Mozilla's design language for
 Firefox, but speaking as someone that's mildly red-green colour-blind,
 please don't differentiate important states solely through a
 red/green/grey/orange colour change.  Even for colour-blind users that can
 tell a difference if they actually look at it (such as myself) the
 difference isn't going to be attention grabbing and may as well not exist.

 For .onion addresses, why not just add a Green onion icon beside whatever
 existing icon/text Firefox already uses to communicate HTTPS information?

 Something like this:
 https://trac.torproject.org/projects/tor/attachment/ticket/23247/onion-
 mockup.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] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * Attachment "onion-mockup.png" added.


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

Re: [tor-bugs] #24457 [Core Tor/Tor]: Integrate tor-android build files directly into tor.git

[Tor Bug Tracker & Wiki]

#24457: Integrate tor-android build files directly into tor.git
-+--
 Reporter:  n8fr8|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mobile, android  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+--
Changes (by ahf):

 * cc: ahf (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] #24457 [Core Tor/Tor]: Integrate tor-android build files directly into tor.git

[Tor Bug Tracker & Wiki]

#24457: Integrate tor-android build files directly into tor.git
-+--
 Reporter:  n8fr8|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  mobile, android  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+--
Changes (by catalyst):

 * sponsor:   => Sponsor8-can
 * 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] #16672 [Applications/Tor Browser]: Text rendering allows font fingerprinting

[Tor Bug Tracker & Wiki]

#16672: Text rendering allows font fingerprinting
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-fonts, tbb-5.5,   |  Actual Points:
  TorBrowserTeam201603   |
Parent ID:  #18097   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 The situation with the current TBB (7.0.10) looks improved, the
 ~dcf/fonttest.html has the same fingerprint for me. However, per:
 browserleaks.com/fonts

 in the "JS Fonts (classic)" test, the fallback metrics/fonts are different
 between different test systems.

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

Re: [tor-bugs] #24458 [Metrics/Onionoo]: Specify Onionoo's query and search syntax

[Tor Bug Tracker & Wiki]

#24458: Specify Onionoo's query and search syntax
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 The standard(s) Onionoo wants to confirm to need to be chosen/defined.  As
 said above, the decoding of plus to space is only a historic part of form
 submission.  Keeping plus or do the percent encoding is valid according to
 URI/URL encoding (as pointed out in comment 4 #24384).  Thus, it needs to
 be decided what Onionoo expects and once a standard is chosen the open
 parts or deviations (all mostly regarding encoding) need to be added to
 the [https://metrics.torproject.org/onionoo.html#methods search-
 definition] (of course, making sure Onionoo conforms to them in first
 place).
 Relay Search should follow Onionoo's standard, which should have Relay
 Search in mind when working on this ticket in order to minimize the
 development efforts for both products.

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

Re: [tor-bugs] #24050 [Core Tor/Tor]: We still do client-side caching. We just don't use the cache.

[Tor Bug Tracker & Wiki]

#24050: We still do client-side caching. We just don't use the cache.
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, ???-backport, review-  |  Actual Points:
  group-26   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by arma):

 I would argue 'no backport', on the theory that everything was basically
 ok before, and this change is just cleaning things up so we don't hurt
 ourselves in 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] #24384 [Metrics/Onionoo]: Decode percent-encoded characters in qualified search terms

[Tor Bug Tracker & Wiki]

#24384: Decode percent-encoded characters in qualified search terms
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Onionoo-1.9.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:11 karsten]:
 > Replying to [comment:10 iwakeh]:
 > > Waiting for #24458.
 >
 > Unclear. We might answer some of the open issues above before moving
 forward with #24458. And maybe it will be easier in this order. Maybe
 let's do both in parallel.

 I think, the unambiguous Relay Search bullet points from comment:8, that
 identify deviations from general standards, should become Relay Search
 tickets.  The remaining need to be discussed on different tickets, if
 unrelated to Onionoo or on #24458, if the topic concerns both.

 For this ticket I see three options:
 1) merge as-is and then work on #24458 to identify what standards should
 be met and work toward the newly set goals.
 2) only merge the double-quote-fix without the plus-encoding-decoding
 parts and then proceed with #24458 as in 1).
 3) leave this ticket open and do #24458 first.

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

Re: [tor-bugs] #24130 [Webpages/Website]: Design/layout for support.tpo based on wireframe

[Tor Bug Tracker & Wiki]

#24130: Design/layout for support.tpo based on wireframe
--+--
 Reporter:  isabela   |  Owner:  antonela
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24129| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 New Iteration based on this week comments.
 Main changes: Copy + Body font-size.

 https://marvelapp.com/4471ig9/screen/35210130

 Make comments as always!

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: hola@… (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] #15251 [Core Tor/Tor]: Make tor support starting with 10.000 Tor Hidden Service

[Tor Bug Tracker & Wiki]

#15251: Make tor support starting with 10.000 Tor Hidden Service
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, scalability, tor-dos  |  Actual Points:
Parent ID:| Points:  10
 Reviewer:|Sponsor:
--+

Comment (by naif):

 GlobaLeaks project do integrate Tor with dynamic setup of Tor Onion
 Services and by Q1/2018 will release a project that require setup of about
 9600 Tor Onion Services, so we will probably work on it somehow.

 Each GlobaLeaks instance will have it's own HTTPS certificate enrolled and
 maintained automatically with LetsEncrypt and it's own Onion Service.

 This project will be setting up a virtual GlobaLeaks for each italian
 public agencies in an automated way, as a massive-scale anti-corruption
 project.

 If someone is going or willing to support Tor debugging to achieve that
 goal, we'll be more than happy.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24471 [Internal Services/Service - jenkins]: Stem jenkins tests unable to invoke tor

[Tor Bug Tracker & Wiki]

#24471: Stem jenkins tests unable to invoke tor
-+
 Reporter:  atagar   |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Hi lovely sysadmins. Our jenkins tests are failing due to being unable to
 find tor...

 https://jenkins.torproject.org/job/stem-tor-ci/

 {{{
   checking stem version... 1.6.0-dev
   checking tor version...  failed

 ./RESULT/tor --version returned exit status 127
 }}}

 This happened before on...

 https://trac.torproject.org/projects/tor/ticket/22790

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 I think it would be nice to give the user a hint that an onion connection
 is encrypted. Maybe the icon could be a padlock superimposed on an onion?
 Or we could continue to show the padlock but use the word "Onion" instead
 of "Secure".

 Of course, there's the added complication of that the padlock might be
 intended to convey both "encrypted" and "externally authenticated", but
 that model isn't quite the same for onions. I'm not sure how to deal with
 this complication.

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Right now you can't get a DV onion cert. There's a recent thread on
 drafting a ballot to allow them in the CAB Forum, with early support, but
 there's no guarantee it will pass. No DV onion certs means no Let's
 Encrypt. And once DV is allowed, LE would need to develop the software
 needed to validate .onions automatically, which would take some time as
 well.

 ---

 My thoughts:

 Graphics wise I think all of them look good.

 I don't think we should put the word 'Onion' either though. In fact, doing
 so overloads the location where EV data is displayed, so if I got a
 company called 'Onion' I could make it look like I had an onion address!

 I'm not sure what the (i) button is intended to show graphics wise. "There
 is information for you to review here"? I presume it opens the current
 doorhanger thing that lets you get certificate information and review
 permissions.


 I don't know if there was a path forward agreed upon that was not
 documented here, but policy-wise this is a bit different from what I at
 least envisioned.

 1) An HTTP Onion is Orange. Orange indicates a warning state. I don't
 believe we should communicate that HTTP Onion is 'warning'. It's almost
 always better than HTTP in fact, which we give 'grey' treatment. So I
 think HTTP+Onion should either be Grey or Green.

 2) EV HTTPS + Onion has an info bubble but does not display the company
 name like EV does for HTTPS. I think we should be consistent here and
 display the company name here.

 3) I don't understand why HTTPS onion lacks a (i) but self-signed HTTPS
 onion has it. Both of them should let you review the information. So the
 (i) definetly is implying some sort of state about the website, but it's
 confusing what I'm supposed to be able to draw from this.

 4) It seems like we need to make a decision: is a self-signed SSL cert on
 a .onion:
 a) completely meaningless
 b) an indicator something is wrong
 c) an indicator of trust.

 These would correspond to:
 a) the same icon as a http onion
 b) an orange or red icon
 c) a green icon

 I don't think a self-signed cert is an indicator of trust, so it wouldn't
 automatically mean it gets a green icon. I also don't think it's an
 indicator something is wrong, so automatically giving it orange or red are
 out too.  So it should match an HTTP Onion icon *but* allow you to view
 the certificate in the doorhanger.

 My 2 cents.

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

Re: [tor-bugs] #24050 [Core Tor/Tor]: We still do client-side caching. We just don't use the cache.

[Tor Bug Tracker & Wiki]

#24050: We still do client-side caching. We just don't use the cache.
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, ???-backport, review-  |  Actual Points:
  group-26   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => merge_ready
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.1.x-final


Comment:

 yikes; that was indeed unrelated. Sorry!

 Added a fixup commit and squashed as `bug24050_029_squashed`, then added a
 unit test fix.

 Merged to 032 and forward; marking for possible backport.

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

Re: [tor-bugs] #24384 [Metrics/Onionoo]: Decode percent-encoded characters in qualified search terms

[Tor Bug Tracker & Wiki]

#24384: Decode percent-encoded characters in qualified search terms
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Onionoo-1.9.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Replying to [comment:10 iwakeh]:
 > Waiting for #24458.

 Unclear. We might answer some of the open issues above before moving
 forward with #24458. And maybe it will be easier in this order. Maybe
 let's do both in parallel.

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

Re: [tor-bugs] #24458 [Metrics/Onionoo]: Specify Onionoo's query and search syntax

[Tor Bug Tracker & Wiki]

#24458: Specify Onionoo's query and search syntax
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I'm not sure how to move this forward.

 My analysis in #24384 pointed out some issues in Relay Search, which need
 fixing or at least clarification.

 My idea was to wait until Relay Search does something that conforms to
 standards and then make sure Onionoo responds accordingly.

 If it turns out that Onionoo needs to do something that is not exactly
 standard, like not decode `+` to spaces, we'll have to see how to build
 that. For example, it might be that we cannot leave parameter parsing to
 Jetty anymore.

 If you have a better idea to move this ticket forward without first
 looking at #24384, please go ahead!

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

Re: [tor-bugs] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Replying to [comment:2 karsten]:
 > your second Idea 4

 Oops, meant that to be "Idea 5"  I just edited comment:1 to fix it.

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

Re: [tor-bugs] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 From a parsing POV, your second Idea 4 would be easiest. I don't really
 see a problem with not being able to distinguish point events from single-
 day events, because 1 day is the smallest amount of time we're processing
 on Tor Metrics anyway. (We're discarding timestamps as part of the parsing
 process.)

 But any of the others will do. I'd say just pick whatever you like most.

 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] #24260 [Metrics/Website]: Add metrics timeline events underneath graphs

[Tor Bug Tracker & Wiki]

#24260: Add metrics timeline events underneath graphs
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * keywords:  ux-team => ux-team metrics-timeline


Comment:

 Replying to [comment:10 dcf]:
 > Replying to [comment:6 karsten]:
 > >  - Changed date column to better distinguish single-day entries from
 entries starting or ending on a given day:
 > >- Entries without end date to "-MM-DD and ongoing" (if this
 sounds like Bad English, let's try to find something else that starts with
 the -MM-DD part for better alignment with the other entries).
 >
 > Speaking of this, I want to resolve the ambiguity that currently exists
 between point events (like browser releases) and events that started but
 haven't finished yet ("ongoing"). Both cases are currently represented in
 the table as `start="something", end=""`. But that's a topic of another
 ticket.

 I started #24470 with some ideas for disambiguation.

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

Re: [tor-bugs] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 I've been brainstorming ways to represent the distinction.

 === Idea 1 ===

 Put a mark (like `x`, `/`, `.`) in the `end date` column of point events.
 Leave the "end date" blank for ongoing events.

 ||=start date =||=end date =||=description =||
 ||2017-10-05 ||/ ||geoip database updated. ||
 ||2017-10-07 || ||Increase of users in Romania. ||

 === Idea 2 ===

 Put a keyword like `?` or `ongoing` in the "end date" column of ongoing
 events. Leave the "end date" of point events blank.

 ||=start date =||=end date =||=description =||
 ||2017-10-05 || ||geoip database updated. ||
 ||2017-10-07 ||ongoing ||Increase of users in Romania. ||

 === Idea 3 ===

 Combination of !#1 and !#2. Could help to prevent errors. Entries with a
 blank "end date" would have an undefined meaning.
 ||=start date =||=end date =||=description =||
 ||2017-10-05 ||/ ||geoip database updated. ||
 ||2017-10-07 ||ongoing ||Increase of users in Romania. ||

 === Idea 4 ===

 Have the date of point events span both columns. Looks nice(?), greatly
 complicates downstream parsing.

 ||=start date =||=end date =||=description =||
 ||2017-10-05 || ||geoip database updated. ||
 ||
 {{{#!td colspan=2 align=center
 2017-10-07
 }}}
 ||Increase of users in Romania. ||

 === Idea 4 ===

 Point events simply have "start date"="end date". Doesn't allow to
 distinguish point events from timespans than happened to start and finish
 on the same day. (Not currently a problem, as the only such timespans we
 have so far are additionally disambiguated by timestamps.)

 ||=start date =||=end date =||=description =||
 ||2017-10-05 ||2017-10-05 ||geoip database updated. ||
 ||2017-10-07 || ||Increase of users in Romania. ||

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nullius):

 Replying to [comment:22 cypherpunks]:
 > Do you have any actual evidence that they intercepted these decrypted
 packets ''and'' used them for their own malicious goals, or those of other
 3-letter entities? Otherwise this talk is pure gossip, and it belongs on
 tabloids of the DailyMail.

 First off, I ''do'' have evidence that they “intercepted these decrypted
 packets”.  That is how Cloudflare works, period.  If you fail to
 comprehend this, then go back and reread this thread—or read Cloudflare’s
 own documentation—or for that matter, try learning how TLS actually works.
 Without full interception and decryption of each and every connection, it
 would impossible for them to scan application-layer requests for
 “attacks”, insert their own HTTP response headers, and return cache items
 from their own servers.  Even with their misleadingly named “keyless SSL”,
 their diagrams make explicit that they hold the TLS session keys
 (symmetric keys) for all sessions (only in that case, not the server
 certificate private keys).

 As for the rest:

 Absence of evidence is not evidence of absence; and your proposition is
 diversionary, whereas the real issue is one of ''trust'' and of the
 promises made by TLS.

 Fact:  Cloudflare performs mass decryption, then says in essence, ''Trust
 us.''

 Evidently, you accept that.  For comparison, would you accept key escrow?
 There is no “actual evidence” that police agencies would abuse that power,
 or that blackhats would steal the escrowed keys.  (There is no such
 evidence, only because no such system has ever existed in the wild and at
 scale.)  Also, ''reductio ad absurdum'', would you accept centralized
 decryption of 100% of Web traffic?  90%?  At what threshold would you deem
 such a power a threat in itself?  Whom would you trust to have it?

 You have no evidence that Cloudflare does not misuse this power, other
 than their solemn promise that they don’t.  In other words, no “actual
 evidence”.  But that is beside the point:  Nobody should demand that level
 of trust, on today’s Internet, in today’s world.  The creation of a mass-
 decryption chokepoint is implicitly malicious.

 Sane people prefer to trust cryptographic algorithms.  That is exactly why
 we have such things in the first place.  Why even bother with TLS?  Why
 not simply trust large, reputable companies to deliver packets without
 peeking at them?

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

Re: [tor-bugs] #24462 [Metrics/Compass]: Redirect all queries to Relay Search

[Tor Bug Tracker & Wiki]

#24462: Redirect all queries to Relay Search
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24445   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => merge_ready


Comment:

 Looks fine. Will merge and deploy in a month from now. (If I forget,
 please remind me!) Thanks!

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

Re: [tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by dgoulet:

Old description:

> I noticed this on my v3 hidden service info logs which happened on Nov
> 22nd:
>
> {{{
> Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last
> hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
> $77159B89F39708B27CAC528FF32DD786569A11A5(open)
> $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
> $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
> Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
> circuit_send_next_onion_skin() failed.
> Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin)
> failed.
> Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
> Closing.
> }}}
>
> So that circuit ^ has a Guard
> (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or
> so before:
>
> {{{
> Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
> Removing sampled guard lovejoy
> ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
> ago, and confirmed over 60 days ago.
> }}}
>
> Turns out that the circuit was cannibalized but tor made it failed
> because I assume our guard state wasn't available for that circuit which
> ultimately triggered those warnings. asn informed me that it is important
> that the circuit with old guard(s) stay alive for a while to help
> mitigate Guard discovery attacks.
>
> Bottom line, I think our cannibalized function should exclude any circuit
> that doesn't match our guard state. In the meantime, those warnings will
> appear in the logs.

New description:

 I noticed this on my v3 hidden service info logs which happened on Nov
 22nd:

 {{{
 Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop
 ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
 $77159B89F39708B27CAC528FF32DD786569A11A5(open)
 $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
 $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
 Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
 circuit_send_next_onion_skin() failed.
 Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin)
 failed.
 Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
 Closing.
 }}}

 So that circuit above has a Guard
 (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or
 so before:

 {{{
 Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
 Removing sampled guard lovejoy
 ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
 ago, and confirmed over 60 days ago.
 }}}

 Turns out that the circuit was cannibalized but tor made it failed because
 I assume our guard state wasn't available for that circuit which
 ultimately triggered those warnings. asn informed me that it is important
 that the circuit with old guard(s) stay alive for a while to help mitigate
 Guard discovery attacks.

 Bottom line, I think our cannibalized function should exclude any circuit
 that doesn't match our guard state. In the meantime, those warnings will
 appear in the logs.

--

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

Re: [tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [ticket:24469 dgoulet]:
 > I noticed this on my v3 hidden service info logs which happened on Nov
 22nd:
 >
 > {{{
 > Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last
 hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
 $77159B89F39708B27CAC528FF32DD786569A11A5(open)
 $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
 $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
 > Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
 circuit_send_next_onion_skin() failed.
 > Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at
 origin) failed.
 > Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
 Closing.
 > }}}
 >
 > So that circuit above has a Guard
 (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or
 so before:
 >
 > {{{
 > Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
 Removing sampled guard lovejoy
 ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
 ago, and confirmed over 60 days ago.
 > }}}
 >
 > Turns out that the circuit was cannibalized but tor made it failed
 because I assume our guard state wasn't available for that circuit which
 ultimately triggered those warnings. asn informed me that it is important
 that the circuit with old guard(s) stay alive for a while to help mitigate
 Guard discovery attacks.
 >
 > Bottom line, I think our cannibalized function should exclude any
 circuit that doesn't match our guard state. In the meantime, those
 warnings will appear in the logs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:  metrics-timeline
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The metrics timeline does not distinguish entries that represent a single
 point in time from those that started but have not finished yet. They both
 are represented by a non-empty `start date` column and an empty `end date`
 column. For example (some columns omitted):
 ||=start date =||=end date =||=description =||
 ||2017-10-05 || ||geoip database updated. ||
 ||2017-10-07 || ||Increase of users in Romania. ||

 We need to disambiguate these two cases for the sake of uses like #24260,
 which wants to present date ranges as text.

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

Re: [tor-bugs] #24467 [Core Tor/Tor]: Enable -Wnormalized=nfkc when available to avoid source code identifier confusion

[Tor Bug Tracker & Wiki]

#24467: Enable -Wnormalized=nfkc when available to avoid source code identifier
confusion
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Patch ready, needs review!

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

Re: [tor-bugs] #24467 [Core Tor/Tor]: Enable -Wnormalized=nfkc when available to avoid source code identifier confusion

[Tor Bug Tracker & Wiki]

#24467: Enable -Wnormalized=nfkc when available to avoid source code identifier
confusion
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * Attachment "0001-Switch-Wnormalized-id-to-Wnormalized-nfkc.patch" added.


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

[tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-circuit
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I noticed this on my v3 hidden service info logs which happened on Nov
 22nd:

 {{{
 Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop
 ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
 $77159B89F39708B27CAC528FF32DD786569A11A5(open)
 $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
 $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
 Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
 circuit_send_next_onion_skin() failed.
 Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin)
 failed.
 Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
 Closing.
 }}}

 So that circuit ^ has a Guard (`175921396C7C426309AB03775A9930B6F611F794`)
 that was removed a minute or so before:

 {{{
 Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
 Removing sampled guard lovejoy
 ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
 ago, and confirmed over 60 days ago.
 }}}

 Turns out that the circuit was cannibalized but tor made it failed because
 I assume our guard state wasn't available for that circuit which
 ultimately triggered those warnings. asn informed me that it is important
 that the circuit with old guard(s) stay alive for a while to help mitigate
 Guard discovery attacks.

 Bottom line, I think our cannibalized function should exclude any circuit
 that doesn't match our guard state. In the meantime, those warnings will
 appear in the logs.

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|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] #22958 [Webpages/Website]: Update website FAQ about padding defenses

[Tor Bug Tracker & Wiki]

#22958: Update website FAQ about padding defenses
--+--
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website, website-content  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * milestone:   => website redesign


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

Re: [tor-bugs] #21519 [Webpages/Website]: Tor Project FAQ

[Tor Bug Tracker & Wiki]

#21519: Tor Project FAQ
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  FAQ website   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * milestone:   => website redesign


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

Re: [tor-bugs] #19756 [Webpages/Website]: research.tp.o suggests mailing tor-assistants

[Tor Bug Tracker & Wiki]

#19756: research.tp.o suggests mailing tor-assistants
--+--
 Reporter:  arma  |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

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


Comment:

 This got fixed when the page was redone, presumably to add the safety
 board info.

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

Re: [tor-bugs] #23332 [Internal Services/Service - trac]: Change Trac Username

[Tor Bug Tracker & Wiki]

#23332: Change Trac Username
--+--
 Reporter:  bkerensa@…|  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

 * status:  new => assigned
 * owner:  (none) => hiro
 * component:  Webpages/Website => Internal Services/Service - trac


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

Re: [tor-bugs] #24465 [Applications/Tor Launcher]: 'missing pluggable transport ' error when trying to connect to Tor using snowflake

[Tor Bug Tracker & Wiki]

#24465: 'missing pluggable transport ' error when trying to connect to Tor using
snowflake
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team snowflake  |  Actual Points:
Parent ID:  #24371 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mcs):

 For what its worth, I am also unable to reproduce this. I tried on an
 Ubuntu 14.04.5 system with a Tor Browser that was upgraded from 7.5a6 to
 7.5a8.

 I wonder if snowflake-client is crashing or refusing to start, and why.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:21 nullius]:
 > Replying to [comment:18 cypherpunks]:
 > > It shouldn't extend to how someone sets up their website, otherwise it
 opens a slippery slope: why not block all websites because all servers
 have the backdoor that is Intel Management Engine or AMD's Platform
 Security Processor?
 >
 > For the purposes of this bug, suggestions that some shadowy somebody may
 be using a hardware backdoor for the whole Internet do not equate to the
 certain knowledge that one clearly identified entity is ''in fact''
 performing realtime decryption of all TLS connections to millions of
 websites ''right now''.

 Do you have any actual evidence that they intercepted these decrypted
 packets ''and'' used them for their own malicious goals, or those of other
 3-letter entities? Otherwise this talk is pure gossip, and it belongs on
 tabloids of the DailyMail.

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

Re: [tor-bugs] #22703 [Core Tor/Tor]: Add a KeyDirectory option to override location of $datadir/keys, and/or a cachedir option to override location of cached files.

[Tor Bug Tracker & Wiki]

#22703: Add a KeyDirectory option to override location of $datadir/keys, and/or 
a
cachedir option to override location of cached files.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sponsor8-maybe, configuration,   |  Actual Points:  1
  torrc, review-group-26 |
Parent ID:  #7176| Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by dgoulet):

 This is pretty big, can you make an oniongit merge request please nickm?

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

Re: [tor-bugs] #23505 [Webpages/Website]: Update torproject.org title / tab

[Tor Bug Tracker & Wiki]

#23505: Update torproject.org title / tab
--+
 Reporter:  steph |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


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

Re: [tor-bugs] #23586 [Webpages/Website]: fingerprint in documentation is wrong

[Tor Bug Tracker & Wiki]

#23586: fingerprint in documentation is wrong
--+--
 Reporter:  kkuehl@…  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  gpg fingerprint   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by hiro):

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


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

Re: [tor-bugs] #20020 [Core Tor/Tor]: Strange Warning: "Couldn't add re-parsed router: Some certs on this router are expired."

[Tor Bug Tracker & Wiki]

#20020: Strange Warning: "Couldn't add re-parsed router: Some certs on this 
router
are expired."
-+-
 Reporter:  torland  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.7
 Severity:  Normal   | Resolution:
 Keywords:  prop220-fallout, usability,  |  Actual Points:
  logging, relay, review-group-26|
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

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

Re: [tor-bugs] #24050 [Core Tor/Tor]: We still do client-side caching. We just don't use the cache.

[Tor Bug Tracker & Wiki]

#24050: We still do client-side caching. We just don't use the cache.
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, ???-backport, review-  |  Actual Points:
  group-26   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Hmmm... commit `be973b3f38386c84` has this but doesn't seem relevant to
 the fix at all?

 {{{
 +  int fd; /**< FD for the file, if it's extensible. */
 }}}

 Else lgtm;

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

Re: [tor-bugs] #24346 [Core Tor/Tor]: prop224: Service stops uploading one of its two descriptors

[Tor Bug Tracker & Wiki]

#24346: prop224: Service stops uploading one of its two descriptors
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 See branch for the added logging statements: `ticket24346_032_01`

 Once merged, lets move this ticket to 033 in `needs_information` because
 without these log statements, I fear understanding whats going on will be
 near impossible.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nullius):

 Replying to [comment:18 cypherpunks]:
 > The green icon only tells you that the exit and the server you're
 communicating to (Cloudflare in this case) is encrypted, and that's it.

 Incorrect.  If that were the case, then anon-DH ciphersuites would be
 acceptable.  Those are also securely 100% military-grade super-duper
 encrypted.  “...and that’s it.”

 The lock icon promises not only encryption, but also authentication of the
 endpoint and protection against MITM attacks.  Among other guarantees.

 > It shouldn't extend to how someone sets up their website, otherwise it
 opens a slippery slope: why not block all websites because all servers
 have the backdoor that is Intel Management Engine or AMD's Platform
 Security Processor?

 For the purposes of this bug, suggestions that some shadowy somebody may
 be using a hardware backdoor for the whole Internet do not equate to the
 certain knowledge that one clearly identified entity is ''in fact''
 performing realtime decryption of all TLS connections to millions of
 websites ''right now''.

 (I’d be thrilled to see a workable solution proposed as for the problem
 you raise, or even a reasonable assessment of its scope.  However, that is
 off-topic to this bug.)

 > Also, good luck confusing most users by blocking a large portion of the
 web:

 Users are being confused ''right now''.  They are being scammed by a
 promise of a “secure” connection to a certain identified website.
 Instead, they are being silently provided a “secure” connection to
 Cloudflare.  Not on one website, or even only a few, but across
 ''millions'' of websites.  The aggregate effect is critical to
 understanding the mass-surveillance implications.

 This bug is about solving user confusion, with warnings or errors as
 appropriate to different levels on the Security Slider.

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

Re: [tor-bugs] #24425 [Core Tor/DirAuth]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
--+
 Reporter:  nickm |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #24425 [Core Tor/DirAuth]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
--+
 Reporter:  nickm |  Owner:  dgoulet
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Replying to [comment:3 asn]:
 > Thanks for the useful analysis. I'm fine with bumping up
 `hsdir_spread_store` and it seems like a good move.

 We have two choices, bump it in 032 code or/and via consensus param. Since
 032 is not stable yet, I think we can just sweep in and change it in the
 code then once released we can quickly change it if needed via consensus.

 See branch that bumps the value to 4 in the code: `ticket24425_032_01`

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nullius):

 Suggestion:  Instead of using some ''ad hoc'' “pass” scheme to distinguish
 “good” from “bad” traffic, Cloudflare and Tor Browser should both
 implement an Internet Standard, [https://tools.ietf.org/html/rfc3514 RFC
 3514].  If Tor Browser may consider implementing such a feature, should I
 open a new bug for this?

 N.b. that this suggested implementation does not ''eliminate'' CAPTCHAs.
 Rather, it turns so-called “challenges” into an in-browser currency whilst
 snookering the user into serving as a [https://xkcd.com/1897/ mechanical
 Turk].  Thus, it is perhaps the worst form of micropayments ever
 conceived.  As a more general issue, users should be educated on the
 current market value of their time and “Attention Required!” attention
 performing mind-numbingly boring tasks on behalf of computers:  The new
 masters, whom humans are hatched to serve.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nullius):

 * severity:  Blocker => Major


Comment:

 The enthusiasm for solving this problem is commendable; but as a practical
 matter, I doubt that much could be achieved by throwing “Blocker” severity
 into the mundane workflow of bug management.

 I suggest instead that it would be productive to raise awareness of this
 issue, answer the rather specious counterarguments which have been raised,
 and—write some code!  “Cypherpunks write code.”

 As for code:  Does anyone interested in this bug have a starting idea for
 where to hook this feature into either Torbutton or Firefox?  I’m
 `main()`ly a C wrangler, and not really familiar with the codebase of
 either.  From an architectural standpoint, it would be wise to patch this
 by some means which could later be ported to other browsers, and/or lifted
 out into its own extension.  That way, users of other browsers could
 ultimately benefit from our efforts here.

 As for awareness:  Even in tech circles, it seems that most people don’t
 even stop to think about how Cloudflare works, or what the implications
 could be.  I suppose also that those who do, may simply shrug in
 resignation:  Cloudflare is too big, too powerful; people are too
 apathetic about privacy and security.  I say this based on my own
 experience.  The “oh, duh!” moment came for me in 2015, when I was
 designing my own little hack on TLS and paused to wonder how Cloudflare
 does this.  ''They decrypt everything.  Of course.''  After that, I simply
 never spoke up about this, because it seemed that nobody cared.

 On that last point, the responses on this bug have proved me wrong.  I
 intend to respond to some of the points raised above.  Also, I suggest we
 should carry on this discussion and get the word out—perhaps, organize in
 another venue.  Tor should be activism-friendly; but this is a bug tracker
 and a Tor Browser bug, where I suggest we ought try to focus on how ''and
 why'' to fix this in Tor Browser.  Beyond that—any takers?

 (As for those those who like what I’ve written here:  Feel free to copy
 and share, in whole or in part.  Simply attribute to ''nullius (@)
 nym.zone''.  Thanks for actually giving a damn about this issue.)

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

Re: [tor-bugs] #24468 [Core Tor/Tor]: Measure HSDir usage to guide parameter choices

[Tor Bug Tracker & Wiki]

#24468: Measure HSDir usage to guide parameter choices
+--
 Reporter:  teor|  Owner:  teor
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  privcount-experimental, tor-hs  |  Actual Points:
Parent ID:  #24425  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by dgoulet):

 Replying to [comment:1 asn]:
 > > > - What's the rate of incoming v2/v3/both descs?
 > >
 > > Already implemented, needs a time period.
 > >
 >
 > We could do per hour to get some initial insight?
 >

 I think per-hour is what we want. v3 services upload at a random rate a
 descriptor between 60 min and 120 min so the lower bound is "per-hour"
 (not considering IP rotation)

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

Re: [tor-bugs] #24468 [Core Tor/Tor]: Measure HSDir usage to guide parameter choices

[Tor Bug Tracker & Wiki]

#24468: Measure HSDir usage to guide parameter choices
+--
 Reporter:  teor|  Owner:  teor
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  privcount-experimental, tor-hs  |  Actual Points:
Parent ID:  #24425  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Replying to [ticket:24468 teor]:
 > Split off #24425:
 >
 > Replying to [ticket:24425#comment:5 asn]:
 > > Replying to [ticket:24425#comment:4 teor]:
 > > > If you write down a list of exactly what you want to know, we can
 probably collect some stats on ~18 HSDirs using PrivCount.
 > > ...
 > > here are some basic ideas:
 > >
 > > - How many v2/v3/both descs per HSDir?
 >
 > How is this different to "rate of incoming"?
 >
 > If you mean "cached right now", then I'd need a timeframe so I could
 design an event. I could do this in December or January.
 >

 Yeah I meant "cached right now". How many descs does the HSDir have cached
 at 01:00? At 03:00? At 14:00?

 Perhaps what could be done is a graph with x-axis being time (24 hours),
 and y-axis being boxplots of the number of descriptors through the whole
 observation period. Something like this: https://i.imgur.com/oyryjs4.png

 > > - How much total RAM do all v2/v3/both descs occupy on your hsdirs?
 (max,min,avg,mean over your 18 hsdirs)
 >
 > I think we have some of the data, but I'd need a list of the objects
 that contribute to RAM usage. Do you just want descriptors, or is there a
 replay cache? I could do this in December or January.
 >

 Hm. Don't care much about the replay cache right now, mainly about the
 descs themselves. We could use `rendcache.c:rend_cache_total_allocation`
 (which tracks both v2 and v3), and then `rend_cache_entry_allocation()`
 for v2, and `cache_get_dir_entry_size()` for v3.

 > > - Size variance of v2/v3 descs? (max,min,avg,mean)
 >
 > Already implemented as a histogram, needs defined bin sizes.
 >

 Hm, not sure. Probably depends on the size variance to optimize bin size.

 > > - What's the rate of incoming v2/v3/both descs?
 >
 > Already implemented, needs a time period.
 >

 We could do per hour to get some initial insight?

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by asn):

 Replying to [comment:8 tom]:
 > There's also the notion of showing different icons for self-signed
 .onion (grey onion?) vs DV-ca-signed .onion (green onion?)

 Hm. Reason this idea is good:

 - Will be easier for users to distinguish between real facebook onion (DV-
 ca-signed green onion) and phishing facebook onion (self-signed grey
 onion).

 Reason this idea is bad:

 - It basically gives no way for onion site operators to get the green
 onion without paying the CA mafia.

 How does Let's Encrypt blend into the above idea? Would it give a green-
 onion or not? If yes, then phishers can just use a Let's Encrypt cert to
 get the green onion anyway.

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

Re: [tor-bugs] #24455 [Core Tor/Tor]: messages out of order in the tor log due to stored logs

[Tor Bug Tracker & Wiki]

#24455: messages out of order in the tor log due to stored logs
--+
 Reporter:  darkk |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by darkk):

 > Should "Tor 0.2.7.6 opening new log file." come after the stored logs?

 IMHO it should. Another option is to have some obvious indication that it
 was an //early log//. Time ticking backwards in the log file always looks
 strange and attracts attention.

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

Re: [tor-bugs] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #13837   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:7 mikeperry]:
 > Replying to [comment:6 asn]:
 > > Replying to [comment:5 mikeperry]:
 > > > Asn - you are right to worry about trying to alter how we deal with
 existing purposes, especially in a way that changes the HS state machine.
 However, adding a whole new circuit purpose is quite easy. I have done it
 several times before (including in my draft patch for parent ticket
 #13837). I know how to do it without issue. Aside from a couple asserts
 and checks here and there, new purposes get ignored by existing code.
 That's what circuit purposes are for.
 > > >
 > > > How about this: instead of messing with the existing HS purpose
 state machine(s), we create a new purpose (say
 CIRCUIT_PURPOSE_HS_GENERAL), and then in circuit_predict_and_launch_new()
 we launch new circuits of that type when we predict we need any hidden
 service circuits. Then we should be able to make just a few changes to
 circuit_get_open_circ_or_launch(), circuit_launch_by_extend_info(), and
 circuit_find_to_cannibalize() to use this new circuit type for hidden
 service circuits (instead of using CIRCUIT_PURPOSE_C_GENERAL for them).
 > > >
 > > > That way circuits with this new purpose will otherwise be ignored
 unless we are looking to build a new one. And that mechanism for reusing
 them will be very similar as it is today, just drawing from
 CIRCUIT_PURPOSE_HS_GENERAL instead of CIRCUIT_PURPOSE_C_GENERAL, and we
 also don't have to change our current rephist prediction code.
 > > >
 > > > Sound like a plan?
 > >
 > > Plausible plan. I'm still a bit concerned but I don't have a better
 plan tbh.
 > >
 > > What would be the interaction between `CIRCUIT_PURPOSE_C_GENERAL` and
 `CIRCUIT_PURPOSE_HS_GENERAL`? e.g. would you be able to cannibalize a
 `C_GENERAL` circuit to an `HS_GENERAL` circuit if we find that we have
 idle general circuits and we need HS ones (or the opposite)?
 >
 > The desired behavior is that this should not be allowed. The idea is
 that these two types of general circuits will have different path
 construction mechanisms for the first three hops (vanguards/pinned middles
 vs normal), and should not be mixed.
 >

 Interesting and indeed makes sense for the cases where vanguard-ish
 designs are enabled (e.g. hidden services in the beginning, and maybe even
 HS clients in the future).

 I think we are reaching the point where the cannibalization logic requires
 a small spec of its own to document this stuff (+ various other
 intricacies).

 Another behavior worth documenting: I wonder how the predictive circuit
 launching should work after this change. Should clients create predictive
 general circuits and also create predictive HS circuits? What about HSes?

 > In terms of how this will be done - I am going to alter
 circuit_find_to_cannibalize() so that you must also specify a circuit type
 to cannibalize from in addition to the one you want to create, and you
 can't switch between these classes of circuits (in the case where there is
 nothing to cannibalize in this way, that function can find nothing and
 return NULL, and the calling code in circuit_launch_by_extend_info() will
 build a fresh circuit instead). Since circuit_find_to_cannibalize()
 already behaves as if you specified canibalize_from ==
 CIRCUIT_PURPOSE_C_GENERAL, I don't anticipate that the change to draw from
 CIRCUIT_PURPOSE_HS_GENERAL will be very complicated.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24468 [Core Tor/Tor]: Measure HSDir usage to guide parameter choices

[Tor Bug Tracker & Wiki]

#24468: Measure HSDir usage to guide parameter choices
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  privcount-experimental, tor-hs
Actual Points:|  Parent ID:  #24425
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 Split off #24425:

 Replying to [ticket:24425#comment:5 asn]:
 > Replying to [ticket:24425#comment:4 teor]:
 > > If you write down a list of exactly what you want to know, we can
 probably collect some stats on ~18 HSDirs using PrivCount.
 > ...
 > here are some basic ideas:
 >
 > - How many v2/v3/both descs per HSDir?

 How is this different to "rate of incoming"?

 If you mean "cached right now", then I'd need a timeframe so I could
 design an event. I could do this in December or January.

 > - How much total RAM do all v2/v3/both descs occupy on your hsdirs?
 (max,min,avg,mean over your 18 hsdirs)

 I think we have some of the data, but I'd need a list of the objects that
 contribute to RAM usage. Do you just want descriptors, or is there a
 replay cache? I could do this in December or January.

 > - Size variance of v2/v3 descs? (max,min,avg,mean)

 Already implemented as a histogram, needs defined bin sizes.

 > - What's the rate of incoming v2/v3/both descs?

 Already implemented, needs a time period.

 > - How many failed requests for HS descriptors over time? (percentage
 over total requests?)

 I'm going to implement this in December.

 > These are just the obvious stats that I came up with. We can come up
 with more stuff as we see some results and understand the space better.
 >
 > Let me know if you need help in turning the above sentences into
 methodologies.
 >
 > > We will also need an estimate of how much 1 client / service would
 contribute to each statistic in 10 minutes.
 > >
 >
 > Is that to figure out the noise for differential privacy? Let's try to
 come up with the final stats list and then we can figure this out.

 Yes, that's fine. They only need to be rough estimates.

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

Re: [tor-bugs] #24455 [Core Tor/Tor]: messages out of order in the tor log due to stored logs (was: clock tick backwards in the tor log)

[Tor Bug Tracker & Wiki]

#24455: messages out of order in the tor log due to stored logs
--+
 Reporter:  darkk |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security-low  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => security-low
 * points:   => 0.5
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


Comment:

 I think this is an artifact of our code that stores early logs, then loads
 the config, then opens a log file, and writes stored logs to this file.

 There are two potential bugs here:
 1. Should "Tor 0.2.7.6 opening new log file." come after the stored logs?
 (Probably not?)
 2. Should the times on the stored logs be rounded to the configured
 LogTimeGranularity, or should we choose a safer default for
 LogTimeGranularity?

 Let's think about this in 0.3.3, because LogTimeGranularity is meant to
 protect users, and it clearly isn't protecting the exact time they started
 Tor.

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

Re: [tor-bugs] #24425 [Core Tor/DirAuth]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:4 teor]:
 > If you write down a list of exactly what you want to know, we can
 probably collect some stats on ~18 HSDirs using PrivCount.

 Hey teor,

 I might be hijacking this ticket by suggesting the following stats but
 here are some basic ideas:

 - How many v2/v3/both descs per HSDir?
 - How much total RAM do all v2/v3/both descs occupy on your hsdirs?
 (max,min,avg,mean over your 18 hsdirs)
 - Size variance of v2/v3 descs? (max,min,avg,mean)
 - What's the rate of incoming v2/v3/both descs?
 - How many failed requests for HS descriptors over time? (percentage over
 total requests?)


 These are just the obvious stats that I came up with. We can come up with
 more stuff as we see some results and understand the space better.

 Let me know if you need help in turning the above sentences into
 methodologies.

 > We will also need an estimate of how much 1 client / service would
 contribute to each statistic in 10 minutes.
 >

 Is that to figure out the noise for differential privacy? Let's try to
 come up with the final stats list and then we can figure this out.

 Should we make a separate ticket (child of this one) for this task?

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25, review-group-26   |
Parent ID:  #23100   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 OK great mike! I'm quite happy with the current state of the code!

 Two minor nitpicks and we are ready to roll:

 - I find it a bit awkward that we are calculating `first_hop_succeeded`
 twice in the same way both in
 `circuit_build_times_mark_circ_as_measurement_only()` and in its caller
 `circuit_expire_building()`. I wonder what we could do to only do the
 calculation once. One solution could be to return the value of
 `first_hop_succeeded` from
 `circuit_build_times_mark_circ_as_measurement_only()` and use it in
 `circuit_expire_building()`. Do you think that makes sense or would it be
 uglier?

 - Let's add a note in the function doc of `circuit_any_opened_circuits()`
 that we cache its result as well.

 After these two minor things are resolved, I think the next steps is to
 squash everything, make a new merge request, and mark it as `merge_ready`
 so that Nick can check it out.

 Cheers!

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 https://lists.torproject.org/pipermail/tor-dev/2017-November/012627.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] #24260 [Metrics/Website]: Add metrics timeline events underneath graphs

[Tor Bug Tracker & Wiki]

#24260: Add metrics timeline events underneath graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 I implemented a first version in [https://gitweb.torproject.org/karsten
 /metrics-web.git/log/?h=task-24260 my task-24260 branch] and deployed it
 on Tor Metrics. (It's just presentation, what could go wrong?)

 Please take a look: https://metrics.torproject.org/userstats-relay-
 country.html

 Changes include:
  - Explained in a short sentence where these events come from.
  - Added a notice when possible censorship events are shown (and hidden
 otherwise) saying that events in the table do not necessarily match those
 in the graph.
  - Date columns do not include "and ongoing" for events without end date
 (or "and before" for events without start date), because we'd basically
 add the "and ongoing" part to every single entry. I agree with dcf that
 this is something we should resolve in another ticket. For now we're only
 distinguishing single-day and multi-day events in the table. Should be
 fine for a start.

 Remaining next steps (some as part of this ticket, most as part of new
 tickets):
  - Adapt the format to the News page. (Waiting for some initial feedback
 on the newly deployed table on graph pages first.)
  - Add tooltips to tags explaining them a little more, like "Onion-Routing
 protocol" for "".
  - Make tags clickable by linking them to a page with all events related
 to that tag. (isabela suggested this above and I forgot to mention it
 before.)
  - Maybe make column headers clickable and as a result sort entries
 accordingly.
  - Maybe change the filtering to only show entries for all countries or
 all transports on graphs showing users from all countries or using all
 transports.
  - Add annotations to the graph or even mouseovers.
  - Add optional JavaScript magic that only displays the first entries and
 that lets the user expend the list if there are more.
  - Find categories or standards for link texts for a more consistent
 presentation.
  - Extend events to graphs in other categories than Users and then add
 this table there.
  - Resolve ambiguity that currently exists between point events (like
 browser releases) and events that started but haven't finished yet
 ("ongoing"). Both cases are currently represented in the table as
 `start="something", end=""`.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 They all seem sensible to me, but I haven't run them.
 Does the new arithmetic pass --fragile-hardening on x86_64 and i386?

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

Re: [tor-bugs] #22251 [Core Tor/Tor]: Time to not require Tor relays to support old link versions?

[Tor Bug Tracker & Wiki]

#22251: Time to not require Tor relays to support old link versions?
---+--
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  032-unreached  |  Actual Points:
Parent ID:  #9476  | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * keywords:  032-unreached, => 032-unreached


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