[tor-bugs] #24259 [Core Tor/Tor]: Simulate out-of-disk situations in chutney and/or unit tests?

[Tor Bug Tracker & Wiki]

#24259: Simulate out-of-disk situations in chutney and/or unit tests?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor has a bunch of weird bugs when it runs out of disk space.

 One of the crazy ones that has been driving us mad for more than a decade
 is that relays somehow decide to start publishing a new descriptor once
 per second, forever.

 Can we make a version of the unit tests where all of the disk interactions
 act like the disk is full?

 Can we make a version of the chutney network tests where the disk pretends
 to be full?

 This idea seems like a great one to add to our testing toolbelt.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24258 [Core Tor/DirAuth]: dir auths should set nf_conntimeout_clients param?

[Tor Bug Tracker & Wiki]

#24258: dir auths should set nf_conntimeout_clients param?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I found some more params in the code since we last set params.

 We should grep for networkstatus_get_param() and figure out what params
 are new and if we want to set any of them in the consensus preemptively
 for robustness.

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

Re: [tor-bugs] #24046 [Core Tor]: Building circuits through Fast (actually) relays

[Tor Bug Tracker & Wiki]

#24046: Building circuits through Fast (actually) relays
+
 Reporter:  IgorMitrofanov  |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 Replying to [comment:4 nikita]:
 > So based on the votes, increasing the 100 KB/s threshold won't have much
 effect b/c the measured threshold (which I'm assuming is the 12.5th
 percentile of consensus weight?) is actually below 100 KB/s.

 Yes, correct.

 Though, remember that the measurements are unitless weights. They just
 mean that somebody with a weight of 40 should get less attention than
 somebody with a weight of 60. They *don't* mean that they think the relay
 with a weight of 60 should be able to do 60KBytes/s.

 > A probably impractical suggestion: could something like TorPerf be used
 to decide this threshold? The median *circuit* BW  is around 300 KB/s
 
(https://metrics.torproject.org/torperf.html?start=2017-08-01=2017-10-30=all=public=5mb),
 so having a relay with a lower bandwidth than that will make it very
 likely this relay will be a bottleneck for you.

 In a world where all of the relays are weighted appropriately, raising the
 threshold too much (i.e. discarding too many slower relays) could
 counterintuitively *lower* the median circuit bandwidth, because it would
 shift more load onto the relays that used to be fast, making them less
 fast.

 I think our main problem now is that we are not close enough to this world
 where all of the relays are weighted appropriately.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24257 [Core Tor/Tor]: We should specify what is means for a Tor version to be obsolete

[Tor Bug Tracker & Wiki]

#24257: We should specify what is means for a Tor version to be obsolete
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Atlas hit #24256 because our logic for what Tor versions are obsolete is
 opaque.

 We should try to write it down somewhere better than the
 tor_version_is_obsolete() function. Maybe version-spec.txt is a good
 location?

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

Re: [tor-bugs] #24256 [Metrics/Atlas]: atlas complains "outdated tor version" for too *new* tor versions too

[Tor Bug Tracker & Wiki]

#24256: atlas complains "outdated tor version" for too *new* tor versions too
---+--
 Reporter:  arma   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [ticket:24256 arma]:
 > Tor has some somewhat complicated logic for deciding whether a version
 is obsolete -- see tor_version_is_obsolete(). Is atlas's best plan to try
 to reproduce Tor's logic? Should we try to specify it, e.g. in version-
 spec.txt, so external programs have a chance of getting it right?

 I opened #24257 for the Tor side of this fix.

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

[tor-bugs] #24256 [Metrics/Atlas]: atlas complains "outdated tor version" for too *new* tor versions too

[Tor Bug Tracker & Wiki]

#24256: atlas complains "outdated tor version" for too *new* tor versions too
---+--
 Reporter:  arma   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 https://atlas.torproject.org/#search/moria1
 shows this text at the top:
 "This relay is running an outdated Tor version and should be updated to a
 recent release of Tor that may contain important fixes."

 But the relay is running "Tor 0.3.3.0-alpha-dev". This is not an outdated
 Tor version -- it is *newer* than any of the recommended versions.

 Tor has some somewhat complicated logic for deciding whether a version is
 obsolete -- see tor_version_is_obsolete(). Is atlas's best plan to try to
 reproduce Tor's logic? Should we try to specify it, e.g. in version-
 spec.txt, so external programs have a chance of getting it right?

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

Re: [tor-bugs] #23638 [Core Tor/Tor]: moria1, running 0.3.2.1-alpha-dev, stops getting voted about

[Tor Bug Tracker & Wiki]

#23638: moria1, running 0.3.2.1-alpha-dev, stops getting voted about
-+--
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-diagnosis  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Is there a "Tor relays publish a new descriptor but authorities drop it
 because they think it's only cosmetically different, and then the relay
 waits 18 more hours to publish, thus falling out of the consensus" ticket?
 If so, we should dup this one to that one. If not, we should open one.

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

Re: [tor-bugs] #8684 [Core Tor/Torflow]: bwauth files don't include opinions about Authorities

[Tor Bug Tracker & Wiki]

#8684: bwauth files don't include opinions about Authorities
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #20797| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Sebastian):

 I think that's a feature

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24255 [Webpages/Website]: Download page offers "source" for Tor, but everything else on that page is Tor Browser

[Tor Bug Tracker & Wiki]

#24255: Download page offers "source" for Tor, but everything else on that page 
is
Tor Browser
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our download page offers Tor Browser for various platforms, and also a
 "source" option. But the source option only gives you a Tor tarball, and
 that's not the source for the binaries on that page.

 Maybe we should have a web page for the little-t-tor component, with
 pointers to things including source tarballs.

 And then change the download page to give you pointers on how to
 reconstruct the tor browsers that it offers (which is actually quite hard,
 but that's another matter).

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

Re: [tor-bugs] #9775 [Core Tor/Tor]: Authorities should report when they don't vote Running but some addresses are still reachable

[Tor Bug Tracker & Wiki]

#9775: Authorities should report when they don't vote Running but some addresses
are still reachable
+--
 Reporter:  arma|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth logging reporting easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:9775 arma]:
 > Another option would be for the authority votes to add an annotation
 somewhere, like in their votes, saying "partially reachable" or some such.
 That approach has the benefit that we could automatically have a record
 over time of how big an issue this is.

 I still think this is a good plan.

 (We continue to run into relay operators who enable ipv6, screw it up, and
 wonder why their relay quietly fell out of the consensus.)

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

Re: [tor-bugs] #8684 [Core Tor/Torflow]: bwauth files don't include opinions about Authorities

[Tor Bug Tracker & Wiki]

#8684: bwauth files don't include opinions about Authorities
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth   |  Actual Points:
Parent ID:  #20797| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Dear past arma,

 Why is it that doing #8435 meant that this ticket needed to be done?

 Right now, once enough dir auths run bwauths, the dir auths will basically
 lose all of their consensus flags that have to do with speed -- Fast,
 Guard, etc.

 But, is that a problem?

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

Re: [tor-bugs] #7680 [Applications/Tor Browser]: Have a Tor package that can run Flash safely

[Tor Bug Tracker & Wiki]

#7680: Have a Tor package that can run Flash safely
---+--
 Reporter:  arma   |  Owner:  tbb-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  SponsorJ, needs-triage, flash  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * severity:   => Normal


Comment:

 Like #7008, I think we should work to close the subtickets here, and then
 close this one as wontfix.

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

Re: [tor-bugs] #6851 [Webpages/Website]: Resume allowing website translations

[Tor Bug Tracker & Wiki]

#6851: Resume allowing website translations
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
 |  WebsiteV3
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wants-volunteer, www-team,   |  Actual Points:
  sebastian-0115-triaged, defer-new-website  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * status:  assigned => new
 * cc: phoul (added)


Comment:

 Adding Colin so he knows this is a ticket (and so he can read over it for
 past history lessons).

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

Re: [tor-bugs] #7008 [Applications/Tor Browser]: Make it safe to run Flash in TBB

[Tor Bug Tracker & Wiki]

#7008: Make it safe to run Flash in TBB
--+---
 Reporter:  arma  |  Owner:  mikeperry
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  SponsorJ, needs-triage|  Actual Points:
Parent ID:  #7680 | Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

 * severity:   => Normal


Comment:

 Time has passed, and Flash is going extinct.

 I say we find a way to close all the subtickets, and then close this one
 as wontfix.

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

Re: [tor-bugs] #3340 [Archived/Vidalia]: mention tor weather from the vidalia sharing page?

[Tor Bug Tracker & Wiki]

#3340: mention tor weather from the vidalia sharing page?
--+-
 Reporter:  arma  |  Owner:  chiiph
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Archived/Vidalia  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 This was a good idea back then, but it is no longer back then. Closing
 ticket as obsolete.

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

Re: [tor-bugs] #3024 [Archived/Vidalia]: Ship the warnings from the Tor download page as a Vidalia help page

[Tor Bug Tracker & Wiki]

#3024: Ship the warnings from the Tor download page as a Vidalia help page
--+-
 Reporter:  arma  |  Owner:  chiiph
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Archived/Vidalia  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

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


Comment:

 I'm going to close this one as way obsolete.

 The Tor Browser folks ought to do something similar, but hopefully they
 already know 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] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on (was: There needs to be decimation on what kernel versions the KIST Schedul

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by Dbryrtfbcbhgf):

 *Correction
 decimation -> documentation

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24254 [Core Tor/Tor]: There needs to be decimation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be decimation on what kernel versions the KIST Scheduler
will run on
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 There needs to be decimation on what kernel versions the KIST Scheduler
 will run on. Right now I'm running
 Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab120.11 x86_64) and it looks
 like it is running based off 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] #21697 [Core Tor/Torflow]: torflow bwfiles maybe should be updated

[Tor Bug Tracker & Wiki]

#21697: torflow bwfiles maybe should be updated
--+--
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Here's every bwauth's bwfile:

 maatuska
 {{{

 1 16M
 15 8M
 48 4M
 70 2M
 85 1M
 94 512k
 97 256k
 98 128k
 99 64k
 100 32k
 .
 }}}

 maatuska duplicate
 {{{
 1 16M
 14 8M
 47 4M
 70 2M
 85 1M
 94 512k
 97 256k
 98 128k
 99 64k
 100 32k
 .
 }}}

 moria1
 {{{
 0 64M
 1 32M
 2 16M
 21 8M
 52 4M
 72 2M
 85 1M
 94 512k
 97 256k
 98 128k
 99 64k
 100 32k
 }}}

 gabelmoo
 {{{

 1 32M
 4 16M
 13 8M
 27 4M
 42 2M
 58 1M
 74 512k
 89 256k
 97 128k
 }}}

 bastet
 {{{
 1 8M
 13 4M
 44 2M
 67 1M
 79 512k
 87 256k
 92 128k
 94 64k
 95 32k
 .
 }}}

 faravahar (Singapore)
 {{{
 10 4M
 54 2M
 79 1M
 92 512k
 96 256k
 98 128k
 99 64k
 100 32k
 .
 }}}

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

Re: [tor-bugs] #24253 [Core Tor/Tor]: Update GettingStartedRust.md with new build instructions

[Tor Bug Tracker & Wiki]

#24253: Update GettingStartedRust.md with new build instructions
--+--
 Reporter:  chelseakomlo  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by chelseakomlo):

 * status:  new => needs_review


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

Re: [tor-bugs] #24253 [Core Tor/Tor]: Update GettingStartedRust.md with new build instructions

[Tor Bug Tracker & Wiki]

#24253: Update GettingStartedRust.md with new build instructions
--+
 Reporter:  chelseakomlo  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by chelseakomlo):

 * Attachment "0001-update-rust-getting-started-for-new-build.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] #24253 [Core Tor/Tor]: Update GettingStartedRust.md with new build instructions

[Tor Bug Tracker & Wiki]

#24253: Update GettingStartedRust.md with new build instructions
--+
 Reporter:  chelseakomlo  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As we now build Rust modules in a single binary, the instructions for
 adding a new rust module has changed.

 See attached patch

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

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s, TorBrowserTeam201711R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * keywords:  AffectsTails, tbb-7.0-issues, tbb-regression, tbb-e10s =>
 AffectsTails, tbb-7.0-issues, tbb-regression, tbb-e10s,
 TorBrowserTeam201711R
 * status:  needs_information => needs_review


Comment:

 Verified this patch today against the 52.4.1 stable series.  With this
 patch applied Print to File works as expected when:
  * security.sandbox.content.level is reduced from 2 to either 1 or 0
  * javascript.use_us_english_locale either enabled or disabled

 Issue #23970 should resolve the sandboxing issues.

 Against the 52.4.1 alpha series the patch fails when
 javascript.use_us_english_locale is 'false'.  There appears to be
 disagreement between the firefox and Web Content processes regarding the
 value of the javascript.use_us_english_locale setting in this case.

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

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Conditionally-setlocale-based-on-
 javascript.use_us_e.patch" added.

 Adds checks to use_us_english_locale setting before calling setlocale and
 friends

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (This appears to be waiting on the metrics IPv6 module in #24218.)

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

Re: [tor-bugs] #24192 [Applications/Tor Browser]: When I visit a V3 onion that supplies a invalid certificate, torbrowser will lookup the onion when the get certifice button is clicked

[Tor Bug Tracker & Wiki]

#24192: When I visit a V3 onion that supplies a invalid certificate, torbrowser
will lookup the onion when the get certifice button is clicked
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

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


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

Re: [tor-bugs] #24173 [Core Tor/Nyx]: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency

[Tor Bug Tracker & Wiki]

#24173: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency
--+---
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 My pleasure, thanks for brainstorming this with us!

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

Re: [tor-bugs] #24173 [Core Tor/Nyx]: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency

[Tor Bug Tracker & Wiki]

#24173: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency
--+---
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yurivict271):

 Replying to [comment:15 atagar]:
 > Thanks yurivict271. Agreed with the caveat that I'm gonna leave the
 Gentoo and FreeBSD discussion to folks on those platforms. I'm delighted
 to take patches to make life better for those platforms (as we did with
 the custom Gentoo/FreeBSD messaging for this) but I don't have the
 bandwidth to lead the charge on fixing their python packages.

 This is totally reasonable, thank you for your help!

 Cheers!
 Yuri

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

Re: [tor-bugs] #24173 [Core Tor/Nyx]: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency

[Tor Bug Tracker & Wiki]

#24173: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency
--+---
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  reopened => closed
 * resolution:   => not a bug


Comment:

 Thanks yurivict271. Agreed with the caveat that I'm gonna leave the Gentoo
 and FreeBSD discussion to folks on those platforms. I'm delighted to take
 patches to make life better for those platforms (as we did with the custom
 Gentoo/FreeBSD messaging for this) but I don't have the bandwidth to lead
 the charge on fixing their python packages.

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

Re: [tor-bugs] #24173 [Core Tor/Nyx]: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency

[Tor Bug Tracker & Wiki]

#24173: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yurivict271):

 Replying to [comment:13 atagar]:
 > Uggg, just gave this a try but by default pysqlite installation fails
 with...
 >
 > How would you care to proceed?

 Another way is to request to fix sqlite3 in python packages that are
 missing it. This is actually the right way. I was just hoping that it's
 easier to fix setup.py.

 I would just file bug reports to offending parties, and not do anything in
 nyx itself.

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

Re: [tor-bugs] #24173 [Core Tor/Nyx]: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency

[Tor Bug Tracker & Wiki]

#24173: nyx-2.0.4: setup.py doesn't list sqlite3 as a dependency
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Uggg, just gave this a try but by default pysqlite installation fails
 with...

 {{{
 In file included from src/module.c:24:0:
 src/connection.h:33:21: fatal error: sqlite3.h: No such file or directory
 compilation terminated.
 error: Setup script exited with error: command 'x86_64-linux-gnu-gcc'
 failed with exit status 1
 }}}

 Installing pysqlite requires other packages, for instance on Ubuntu...

 {{{
 sudo apt-get install sqlite3 libsqlite3-dev
 }}}

 https://stackoverflow.com/questions/32083494/error-installing-python-
 pyzipcode

 This is actually a crappier error output than what we presently have
 (allow users to install, but then give an OS specific message on how to
 install sqlite3).

 How would you care to proceed?

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

Re: [tor-bugs] #23759 [Core Tor/Tor]: Refactor common code out of setup_introduce1_data and intro point functions

[Tor Bug Tracker & Wiki]

#23759: Refactor common code out of setup_introduce1_data and intro point 
functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, refactor |
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 nickm says:
 Someday, we should merge this function with the function that makes all
 the link specifiers for extend cells. (Okay to fix later.)

 https://trac.torproject.org/projects/tor/ticket/23577#comment:21

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 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:
 Keywords:  prop224, tor-hs, single-onion,   |  implemented
  ipv6, review-group-25  |  Actual Points:  2
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 Replying to [comment:21 nickm]:
 > Nice patch!  Merging to master.  Some notes:
 >
 >   * Someday, we should merge this function with the function that makes
 all the link specifiers for extend cells. (Okay to fix later.)

 I added a note to #23759 about this: there is a lot of similar link
 specifier code floating around.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24252 [Core Tor/Tor]: undefined reference to evdns_shutdown

[Tor Bug Tracker & Wiki]

#24252: undefined reference to evdns_shutdown
--+
 Reporter:  maddoctor |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.8
 Severity:  Blocker   |   Keywords:  evdns_shutdown
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Using GCC 7.1.0, tor source 0.3.1.8, and libevent 2.1.8.
 At the end of the building process, tor fails to link with
 "undefined reference to evdns_shutdown" in libtor.a (main.c)
 But -levent_extra is in the Makefile, so I can't figure out why it fails.

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 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:
 Keywords:  prop224, tor-hs, single-onion,   |  implemented
  ipv6, review-group-25  |  Actual Points:  2
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

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


Comment:

 Nice patch!  Merging to master.  Some notes:

   * node_get_curve25519_onion_key() should return a const pointer.  I'm a
 bit surprised that this didn't cause a warning.  I've fixed this post-
 merge with a5ef2b619d267c.
   * Someday, we should merge this function with the function that makes
 all the link specifiers for extend cells. (Okay to fix later.)

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  closed => reopened
 * keywords:  tbb-security, TorBrowserTeam201711R => tbb-security,
 TorBrowserTeam201711
 * resolution:  fixed =>
 * cc: legind (added)


Comment:

 Firefox does not like our trick in a WebExtensions context:
 {{{
 1510514437300   addons.webextension.   ERROR   Loading extension
 'null': Reading manifest: Error processing applications.gecko.update_url:
 Error: Access denied for URL data:text/plain,
 1510514437500   addons.xpi-utilsWARNupdateMetadata: Add-on
 https-everywhere-...@eff.org is invalid: Error: Extension is invalid
 (resource://gre/modules/addons/XPIProvider.jsm:963:11) JS Stack trace:
 loadManifestFromWebManifest<@XPIProvider.jsm:963:11 <
 taskimpl_...@task.jsm:319:42 < Handler.prototype.process@Promise-
 backend.js:932:23 < this.promisewalker.walkerl...@promise-backend.js:813:7
 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:747:11 <
 syncloadmanifestfromf...@xpiprovider.jsm:1621:5 <
 updatemetad...@xpiproviderutils.js:1785:21 <
 processfilechan...@xpiproviderutils.js:2009:26 <
 this.xpiprovider.checkforchan...@xpiprovider.jsm:3899:34 <
 this.xpiprovider.star...@xpiprovider.jsm:2839:25 <
 callprovi...@addonmanager.jsm:242:12 <
 _startprovi...@addonmanager.jsm:795:5 <
 addonmanagerinternal.star...@addonmanager.jsm:1005:9 <
 this.addonmanagerprivate.star...@addonmanager.jsm:3062:5 <
 ammanager.prototype.obse...@addonmanager.js:65:9
 }}}
 So, we need something better and need to rebuild the alphas.

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

Re: [tor-bugs] #21222 [Webpages/Website]: Main ticket for website redesign project

[Tor Bug Tracker & Wiki]

#21222: Main ticket for website redesign project
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  project   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by isabela):

 * owner:  linda => isabela


Old description:

> = Why are doing it? =
> == What problems are we trying to fix? ==
> This project aims to fix a few problems that goes beyond just a redesign
> project. Yes, Tor Project website is not the best thing in the world and
> is a big problem that must be fixed. But that are a few other things that
> are part of this problem, which we can't ignore, which are the different
> fronts working to build what 'Tor Project' is, that is growing and this
> growth is part of the 'website' problem. A lot of information have been
> added to torproject.org over the years without a good organizing system
> for it to scale.
>
> Here is a list of some problems easily recognizable with the current
> site:
>
>  * Not localized
>  * Too much information at the front page
>  * Still hard to find information
>  * Hard to add new information (ends up contributing to the mess) and we
> need to add more information because we are growing :) we have a lot to
> share
>  * inconsistency with the design
>
> And we could go on but the point of this doc is not to have a full
> description of all the problems we have just and introduction to set the
> stage for explaining what we are thinking for solution and the steps of
> its implementation.
>
> = How we will do it? =
> Our solution right now is to create new portals to better organize
> information and also at the same time keep torproject.org simple and easy
> to make it easier for first comers to find their way around into what Tor
> is and how to get/use it.
>
> So we will be building:
>
>  * torproject.org - with 'new user' as our main audience for this portal
> [of course with easy way to navigate to the other portals:
>  * dev.torproject.org - short explanation: "all things related to the
> development of free software projects of Tor Project"
>  * community.torproject.org - short explanation: "a umbrella of things
> that are power by our community, or a portal to 'help people help Tor'.
>  * support.torproject.org - user support website
>
> Are we loosing press? FAQs? Donate page? The Blog? No :) the list above
> are the main entrance to all these things. I invite you to read more
> about each of this portal and other work related to this initiative in
> the children tickets (and their children tickets) associated with this
> project. Is a big project and the information written here is a summary
> of the summary ;)
>
> = Why now? =
> Right now we are with fund and a team to carry this work. And we need to
> do this to enable many other great work at Tor to have infrastructure to
> support their project. We believe that these portals will help a lot of
> groups inside of Tor Project to better provide information about their
> work and therefore receive help to do so.
>
> = What have we done =
> ''__*'''this part is not done yet'''*
> __''The story of Tor Project website is long! But to cut it short we will
> talk from 2015 - now (EOY 2017)
>
> This work will be funded by
> [https://docs.google.com/document/d/1pmknfCSWGnVNv9fYdF44nIOV4ThiPKBx9rfAKVP3j2w/edit?usp=sharing
> SIDA] and incorporate work from
> [https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign
> past efforts]. We did some work on the
> [https://trac.torproject.org/projects/tor/wiki/doc/UX/SupportPage support
> page] before this site-wide effort.
>
> = What we will use to build it? =
> '__*this part is not done yet*__'
>
> = Are we planing to test things? =
> Yes, not only our framework but everything! We hope to do as many
> research and test we can, it will all depend on our bandwidth and
> resources. Since we have been working on building this 'testing' and
> 'research' steps into our processes we already have some stuff in place
> that can help us carry those on. We hope to continue to add  more
> resources in this front to be able to do even more of those in the
> future!
>
> This project is actually the first year of a 3 years project where we
> hope to build this user feedback / testing process and have it happening
> in large scale for all the projects we are working on.
>
> = What about translation? =
> We will localize first:
>
>  * torproject.org
>  * support.torproject.org
>
> The languages we will support are our tier1 languages :
> https://storm.torproject.org/shared/o7Rh2S9bsMNN7Eh7C9cKaqxR371pR1AmpRxbu
> --nC34
>
>  1. English - EN
>  1. Farsi - FA
>  

Re: [tor-bugs] #21222 [Webpages/Website]: Main ticket for website redesign project

[Tor Bug Tracker & Wiki]

#21222: Main ticket for website redesign project
--+--
 Reporter:  isabela   |  Owner:  linda
 Type:  project   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by isabela:

Old description:

> = Why are doing it? =
> == What problems are we trying to fix? ==
> This project aims to fix a few problems that goes beyond just a redesign
> project. Yes, Tor Project website is not the best thing in the world and
> is a big problem that must be fixed. But that are a few other things that
> are part of this problem, which we can't ignore, which are the different
> fronts working to build what 'Tor Project' is, that is growing and this
> growth is part of the 'website' problem. A lot of information have been
> added to torproject.org over the years without a good organizing system
> for it to scale.
>
> Here is a list of some problems easily recognizable with the current
> site:
>
>  * Not localized
>  * Too much information at the front page
>  * Still hard to find information
>  * Hard to add new information (ends up contributing to the mess) and we
> need to add more information because we are growing :) we have a lot to
> share
>  * inconsistency with the design
>
> And we could go on but the point of this doc is not to have a full
> description of all the problems we have just and introduction to set the
> stage for explaining what we are thinking for solution and the steps of
> its implementation.
>
> = How we will do it? =
> Our solution right now is to create new portals to better organize
> information and also at the same time keep torproject.org simple and easy
> to make it easier for first comers to find their way around into what Tor
> is and how to get/use it.
>
> So we will be building:
>
>  * torproject.org - with 'new user' as our main audience for this portal
> [of course with easy way to navigate to the other portals:
>  * dev.torproject.org - short explanation: "all things related to the
> development of free software projects of Tor Project"
>  * community.torproject.org - short explanation: "a umbrella of things
> that are power by our community, or a portal to 'help people help Tor'.
>  * support.torproject.org - user support website
>
> Are we loosing press? FAQs? Donate page? The Blog? No :) the list above
> are the main entrance to all these things. I invite you to read more
> about each of this portal and other work related to this initiative in
> the children tickets (and their children tickets) associated with this
> project. Is a big project and the information written here is a summary
> of the summary ;)
>
> = Why now? =
> Right now we are with fund and a team to carry this work. And we need to
> do this to enable many other great work at Tor to have infrastructure to
> support their project. We believe that these portals will help a lot of
> groups inside of Tor Project to better provide information about their
> work and therefore receive help to do so.
>
> = What have we done =
> ''__*'''this part is not done yet'''*
> __''The story of Tor Project website is long! But to cut it short we will
> talk from 2015 - now (EOY 2017)
>
> This work will be funded by
> [https://docs.google.com/document/d/1pmknfCSWGnVNv9fYdF44nIOV4ThiPKBx9rfAKVP3j2w/edit?usp=sharing
> SIDA] and incorporate work from
> [https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign
> past efforts]. We did some work on the
> [https://trac.torproject.org/projects/tor/wiki/doc/UX/SupportPage support
> page] before this site-wide effort.
>
> = What we will use to build it? =
> '__*this part is not done yet*__'
>
> = Are we planing to test things? =
> Yes, not only our framework but everything! We hope to do as many
> research and test we can, it will all depend on our bandwidth and
> resources. Since we have been working on building this 'testing' and
> 'research' steps into our processes we already have some stuff in place
> that can help us carry those on. We hope to continue to add  more
> resources in this front to be able to do even more of those in the
> future!
>
> This project is actually the first year of a 3 years project where we
> hope to build this user feedback / testing process and have it happening
> in large scale for all the projects we are working on.
>
> = What about translation? =
> We will localize first:
>
>  * torproject.org
>  * support.torproject.org
>
> The languages we will support are our tier1 languages :
> https://storm.torproject.org/shared/o7Rh2S9bsMNN7Eh7C9cKaqxR371pR1AmpRxbu
> --nC34
>
>  1. English - EN
>  1. Farsi - FA
>  1. Spanish - ES
>  1. 

Re: [tor-bugs] #21222 [Webpages/Website]: Main ticket for website redesign project (was: Redesigning torproject.org: cleanup and update, content organization, and creating themed portals)

[Tor Bug Tracker & Wiki]

#21222: Main ticket for website redesign project
--+--
 Reporter:  isabela   |  Owner:  linda
 Type:  project   | Status:  assigned
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by isabela):

 * reporter:  linda => isabela


Old description:

> = Background =
>
> Currently, torproject.org has out of date content, inconsistent styling,
> circular navigation, doesn't link to all the torproject-related pages
> (research.torproject.org, for instance), and, in general, is good at
> introducing Tor and giving the download the link to the users (but does
> other things suboptimally).
>
> We think that torproject.org can do so much more--give developers a
> starting place to land, give tech support to new Tor users, gather people
> that want to be involved in the community, give an overview of Tor
> Project Inc., and much more.
>
> = Objective =
>
> The objective is to update torproject.org to be up-to-date, easily
> maintained, and provide useful content to the people that visit it.
>
> For starters, we want to make torproject.org all about the browser and
> tor project organization, and host other content at dev.torproject.org,
> support.torproject.org, and community.torproject.org. We'll start with
> taking inventory of all the information on the current site, brainstorm
> what content we want on the new site, and try to create a website that
> can provide useful information for various people who want to do more
> than just download the browser.
>
> = Misc =
>
> This work will be funded by
> [https://docs.google.com/document/d/1pmknfCSWGnVNv9fYdF44nIOV4ThiPKBx9rfAKVP3j2w/edit?usp=sharing
> SIDA] and incorporate work from
> [https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign
> past efforts]. We did some work on the
> [https://trac.torproject.org/projects/tor/wiki/doc/UX/SupportPage support
> page] before this site-wide effort.

New description:

 = Why are doing it? =
 == What problems are we trying to fix? ==
 This project aims to fix a few problems that goes beyond just a redesign
 project. Yes, Tor Project website is not the best thing in the world and
 is a big problem that must be fixed. But that are a few other things that
 are part of this problem, which we can't ignore, which are the different
 fronts working to build what 'Tor Project' is, that is growing and this
 growth is part of the 'website' problem. A lot of information have been
 added to torproject.org over the years without a good organizing system
 for it to scale.

 Here is a list of some problems easily recognizable with the current site:

  * Not localized
  * Too much information at the front page
  * Still hard to find information
  * Hard to add new information (ends up contributing to the mess) and we
 need to add more information because we are growing :) we have a lot to
 share
  * inconsistency with the design

 And we could go on but the point of this doc is not to have a full
 description of all the problems we have just and introduction to set the
 stage for explaining what we are thinking for solution and the steps of
 its implementation.

 = How we will do it? =
 Our solution right now is to create new portals to better organize
 information and also at the same time keep torproject.org simple and easy
 to make it easier for first comers to find their way around into what Tor
 is and how to get/use it.

 So we will be building:

  * torproject.org - with 'new user' as our main audience for this portal
 [of course with easy way to navigate to the other portals:
  * dev.torproject.org - short explanation: "all things related to the
 development of free software projects of Tor Project"
  * community.torproject.org - short explanation: "a umbrella of things
 that are power by our community, or a portal to 'help people help Tor'.
  * support.torproject.org - user support website

 Are we loosing press? FAQs? Donate page? The Blog? No :) the list above
 are the main entrance to all these things. I invite you to read more about
 each of this portal and other work related to this initiative in the
 children tickets (and their children tickets) associated with this
 project. Is a big project and the information written here is a summary of
 the summary ;)

 = Why now? =
 Right now we are with fund and a team to carry this work. And we need to
 do this to enable many other great work at Tor to have infrastructure to
 support their project. We believe that these portals will help a lot of
 groups inside of Tor Project to better provide information about their
 work and therefore receive help to do so.

 = What have we done =
 

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:66 arthuredelstein]:
 > I foraged through the Windows API
 Have you foraged em'all? :)
 > In this hack
 As it's a hack, could you make it disableable via a pref?
 > just before the file dialog is created, I set a hook function for window
 creation. I use some heuristics to identify the File Dialog window, and
 then I add a second hook that listens for the "Open" command from the user
 (by button click, enter key, or keyboard shortcut).
 and button tap ;)
 > Before the "Open" command can propagate, I check the text in the
 dialog's filename text field to see if it looks like a URI, and if so, I
 clear the text and show an error message to the user explaining that URIs
 are not allowed.
 In the "Open File..." dialog, you can grab that URI and open it, because
 it's a browser! :)
 > I confirmed this approach prevents any DNS leak.
 What DNS leak? You use OS's feature to load URIs using system proxy
 settings or you don't.
 > Instead of clearing the text, it would be better to cancel the "Open"
 command and leave the text unchanged
 and user would say WTF?!
 > but so far I haven't found a way to do that. But I think the usability
 awkwardness is acceptable, especially given that we explain to the user
 what has gone wrong.
 Until TBB can handle URIs...
 > Anyway, the next step will be to turn this into a patch in Tor Browser.
 And check the security suites wouldn't mind.

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

Re: [tor-bugs] #24251 [- Select a component]: circuit_free only circuit number 0

[Tor Bug Tracker & Wiki]

#24251: circuit_free only circuit number 0
--+
 Reporter:  Felixix   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 That log message in circuit_free() logs "0, 0" if it's not your circuit,
 that is, the circuit did not start at you. So this is fine and normal.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24251 [- Select a component]: circuit_free only circuit number 0

[Tor Bug Tracker & Wiki]

#24251: circuit_free only circuit number 0
--+
 Reporter:  Felixix   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi everybody

 {{{ Tor 0.3.2.4-alpha (git-940308f493edd10f) running on FreeBSD with
 Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.4, Zlib 1.2.8, Liblzma 5.2.2,
 and Libzstd 1.3.2. }}}

 The following output can be observed:
 {{{
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 0 (id: 0)
 marked for close at src/or/command.c:585 (orig reason: 512, new reason: 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 287478585 (id:
 0) marked for close at src/or/command.c:585 (orig reason: 512, new reason:
 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 1674209475
 (id: 0) marked for close at src/or/command.c:585 (orig reason: 512, new
 reason: 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 1882566763
 (id: 0) marked for close at src/or/command.c:585 (orig reason: 512, new
 reason: 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 361115214 (id:
 0) marked for close at src/or/command.c:585 (orig reason: 512, new reason:
 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 1845079337
 (id: 0) marked for close at src/or/command.c:585 (orig reason: 512, new
 reason: 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 341507119 (id:
 0) marked for close at src/or/command.c:585 (orig reason: 512, new reason:
 0)
 Nov 12 09:51:20.000 [info] circuit_mark_for_close_: Circuit 270872991 (id:
 0) marked for close at src/or/command.c:585 (orig reason: 512, new reason:
 0)
 ...
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 Nov 12 09:51:20.000 [info] circuit_free: Circuit 0 (id: 0) has been freed.
 ...
 }}}

 I look at a some minutes snap and count the `_mark` vs `_free` messages:
 {{{
 # cat torlog | grep "has been freed" | awk '{print $6}' | uniq -c
 24144 Circuit
 # cat torlog | grep "circuit_mark_for_close_" | awk '{print $6}' | uniq -c
 24143 Circuit
 }}}

 It looks like each `_mark` has a corresponding `_free` (with a difference
 of one). But all `_free` reporting the same number `n_circ_id`. Especially
 this should be (IMHO) avoided by:
 {{{
 circuitlist.c
 ...
 circuit_free(circuit_t *circ)
 ...
   /* We keep a copy of this so we can log its value before it gets unset.
 */
   n_circ_id = circ->n_circ_id;
 ...
   log_info(LD_CIRC, "Circuit %u (id: %" PRIu32 ") has been freed.",
n_circ_id,
CIRCUIT_IS_ORIGIN(circ) ?
   TO_ORIGIN_CIRCUIT(circ)->global_identifier : 0);
 }}}

 Well, the circuits are not effectively freed ? Am I missing something ?

 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] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I foraged through the Windows API and came up with what I think is a
 reasonable solution that works with the modern file dialog. Here's the
 PoC:

 https://gist.github.com/arthuredelstein/376e33ce8d4482561593657036db32e8

 In this hack, just before the file dialog is created, I set a hook
 function for window creation. I use some heuristics to identify the File
 Dialog window, and then I add a second hook that listens for the "Open"
 command from the user (by button click, enter key, or keyboard shortcut).
 Before the "Open" command can propagate, I check the text in the dialog's
 filename text field to see if it looks like a URI, and if so, I clear the
 text and show an error message to the user explaining that URIs are not
 allowed. I confirmed this approach prevents any DNS leak.

 Instead of clearing the text, it would be better to cancel the "Open"
 command and leave the text unchanged, but so far I haven't found a way to
 do that. But I think the usability awkwardness is acceptable, especially
 given that we explain to the user what has gone wrong.

 Anyway, the next step will be to turn this into a patch in Tor Browser.

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