Re: [tor-bugs] #27539 [Applications/Tor Browser]: Create plan for releasing on F-Droid

2019-02-11 Thread Tor Bug Tracker & Wiki
#27539: Create plan for releasing on F-Droid
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201902,|  Actual Points:
  TBA-8.5|
Parent ID:  #26318   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 sysrqb: Could we try to map out the pros and cons for having Tor Browser
 built and distributed via the official F-Droid repo vs. making it
 available via our own one?

 So, assuming we are going the official F-Droid repo route and are getting
 a build script ready that is essentially doing the tor-browser-build on
 F-Droid's infra, how would we make sure that we are actually releasing
 what we got with our own builds? I mean without verification before we go
 live reproducible builds are just a promise. :)

 eighthave: are there ways to incorporate that verification step in the
 whole build process?

 Do we add additional attack surface by relying on F-Droid infra vs.
 setting up our own (and if so, is that worth the benefit)?

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

Re: [tor-bugs] #29470 [Applications/Tor Browser]: error message torBrowser-8.0.5-osx6 No Mountable file systems

2019-02-11 Thread Tor Bug Tracker & Wiki
#29470: error message torBrowser-8.0.5-osx6 No Mountable file systems
--+---
 Reporter:  arw54 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => needs_information


Comment:

 When does this error message appear? As soon as you try to open the Tor
 Browser .dmg file?

 I have a very fuzzy memory of a similar problem from several years ago.
 Usually this means that the downloaded DMG is corrupt. Please check the
 checksum. Also, the following articles might provide some useful ideas:
 https://superuser.com/questions/19426/im-unable-to-mount-a-dmg-getting-a
 -no-mountable-filesystems-error
 https://deciphertools.com/blog/2017-10-02-no-mountable-file-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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

2019-02-11 Thread Tor Bug Tracker & Wiki
#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:24 QZw2aBQoPyuEVXYVlBps]:
 > Replying to [comment:23 cypherpunks]:
 > > If you want a more sane solution and not "sane" - do not touch that
 Mozilla's `if` code block, it's not broken. Add your own `if
 (aIsPrivateBrowsing)` after it. Never use `int64_t` for something with
 `size` in its name. Never use `int64_t()` in C++. Use spellchecker. What
 happens when you `return nullptr;`?
 > We either use their `if` or copy their code to our own if, I think
 reusing their `if` is better than code duplication.
 That's because you don't see the difference.
 > We want the same exact logic to handle either case, so it makes sense to
 use that block.
 And we don't.
 > `int64_t` is what Mozilla uses, I'm just following their code.
 Heh.
 > I tested what happened on `nullptr` return above, see comment 10.
 Exactly. Now think what's wrong.
 > The next patch includes the preference changes, I removed the
 `media.cache_size` preference override
 Good.
 > and added one for `media.memory_cache_max_size`, doubling the default
 value.
 Not good.

 If you want to write a more sane code, you can try to pass Mozilla's
 review on Bugzilla.

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

2019-02-11 Thread Tor Bug Tracker & Wiki
#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, easy, intro,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by neel):

 Is the function `dirserv_set_router_is_running()` the function where a
 dirauth would set itself as running (e.g. the "Reachable" flag)?

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

Re: [tor-bugs] #29475 [Webpages/Website]: jobs link is broken on new website pages

2019-02-11 Thread Tor Bug Tracker & Wiki
#29475: jobs link is broken on new website pages
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Actually, "contact" and "press" are broken here too.

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

Re: [tor-bugs] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

2019-02-11 Thread Tor Bug Tracker & Wiki
#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Replying to [comment:4 mikeperry]:
 > it would not be to hard to augment it to send periodic end-to-end probes
 for introduce1 circuits

 In the original tor-design paper, we spoke of onion services doing spot-
 checks of their introduction points, to make sure that they are actually
 introducing. That approach would test a larger fraction of the system than
 just doing a liveness check within the circuit. Both are kind of messy
 though.

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

Re: [tor-bugs] #29473 [Webpages/Website]: android link from download page behaves weirdly

2019-02-11 Thread Tor Bug Tracker & Wiki
#29473: android link from download page behaves weirdly
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 And "Check out the manual for more troubleshooting tips." points to
 manual.torproject.org, but that site doesn't exist.

 Maybe you meant tb-manual.torproject.org?

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

Re: [tor-bugs] #29473 [Webpages/Website]: android link from download page behaves weirdly

2019-02-11 Thread Tor Bug Tracker & Wiki
#29473: android link from download page behaves weirdly
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Oh, and the Onion Browser link from the download page is broken too (links
 to "")

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

Re: [tor-bugs] #29473 [Webpages/Website]: android link from download page behaves weirdly

2019-02-11 Thread Tor Bug Tracker & Wiki
#29473: android link from download page behaves weirdly
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Oh, and both the "Download .Apk" and "Go To Google Play" links are broken:
 they both link to ""

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

Re: [tor-bugs] #29473 [Webpages/Website]: android link from download page behaves weirdly

2019-02-11 Thread Tor Bug Tracker & Wiki
#29473: android link from download page behaves weirdly
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Replying to [ticket:29473 arma]:
 > (B) I reload the download page, and find myself looking at the top of
 the download page again, even though my browser url has changed to
 > https://lektor-staging.torproject.org/tpo/staging/download/#android

 If I go up the url bar and click on it and then press enter, I do get
 brought to the part of the page that is for android downloads. So there
 clearly *is* an anchor, but the javascript from clicking the robot button
 is not bringing me there.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29475 [Webpages/Website]: jobs link is broken on new website pages

2019-02-11 Thread Tor Bug Tracker & Wiki
#29475: jobs link is broken on new website pages
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Go to e.g.
 https://lektor-staging.torproject.org/tpo/staging/about/people/
 and scroll down and click on 'jobs' near 'our mission'.

 It sends you to
 https://lektor-staging.torproject.org/about/jobs
 which is 404.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29474 [Webpages/Website]: "sign up for tor-dev" broken link from people page

2019-02-11 Thread Tor Bug Tracker & Wiki
#29474: "sign up for tor-dev" broken link from people page
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On the new people page:
 https://lektor-staging.torproject.org/tpo/staging/about/people/
 if you scroll down, you get to the "Sign Up For Tor-dev" link,
 but it is a link to "".

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

Re: [tor-bugs] #29454 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Updates of HTTPS-Everywhere we ship do not seem to update the rulesets

2019-02-11 Thread Tor Bug Tracker & Wiki
#29454: Updates of HTTPS-Everywhere we ship do not seem to update the rulesets
-+-
 Reporter:  gk   |  Owner:  legind
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by legind):

 gk: The extension checks for new rulesets when the browser starts, and
 subsequently at 24 hour intervals.  My guess is that the tor daemon has
 not finished bootstrapping when the initial check takes place, and thus it
 fails for the first try.

 Changing the periodicity to 30 seconds instead of every day, after a
 minute or so the rulesets do update to the latest version:

 {{{
 cd tor-browser_en-
 US/Browser/TorBrowser/Data/Browser/profile.default/extensions
 mkdir https-everywhere
 unzip -qd https-everywhere https-everywhere-...@eff.org.xpi
 sed -i 's/periodicity = 86400;/periodicity = 30;/g' https-everywhere
 /background-scripts/update.js
 rm https-everywhere-...@eff.org.xpi
 cd https-everywhere/
 zip -qr ../https-everywhere-...@eff.org.xpi ./*
 cd .. && rm -rf https-everywhere
 }}}

 Keep in mind that rulesets are still bundled with the extension itself, so
 Tor Browser is still protected with whatever rulesets were present at the
 time of the last full extension release.

 Is there any way that you can notify HTTPS Everywhere when the tor
 bootstrapping process has completed?  I could create a hook for this
 event.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29473 [Webpages/Website]: android link from download page behaves weirdly

2019-02-11 Thread Tor Bug Tracker & Wiki
#29473: android link from download page behaves weirdly
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On the new download page:
 https://lektor-staging.torproject.org/tpo/staging/download/
 click on the little robot picture (which when I hover over it, it says it
 is a link to
 https://lektor-staging.torproject.org/tpo/staging/download/#android)

 Two things happen:

 (A) A separate tab opens, called "Success", for no particular reason that
 I can see:
 https://lektor-staging.torproject.org/tpo/staging/thank-you/
 (what was successful?)

 (B) I reload the download page, and find myself looking at the top of the
 download page again, even though my browser url has changed to
 https://lektor-staging.torproject.org/tpo/staging/download/#android

 I guess what I would have expected would be:

 (A) No weird success tab opens when there isn't anything that was
 successful, and

 (B) It would move me down to the section of the download page which is for
 android downloads.

 (All of this is in Tor Browser for Linux.)

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

Re: [tor-bugs] #29468 [Webpages/Website]: Broken link: "Verify Tor Browser signature here"

2019-02-11 Thread Tor Bug Tracker & Wiki
#29468: Broken link: "Verify Tor Browser signature here"
--+--
 Reporter:  intrigeri |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 i closed #29469 as a duplicate

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

Re: [tor-bugs] #29469 [Webpages/Website]: Broken verify signature link

2019-02-11 Thread Tor Bug Tracker & Wiki
#29469: Broken verify signature link
--+---
 Reporter:  tom   |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

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


Comment:

 closing in favor of #29468 which looks like the same 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] #29176 [Webpages/Website]: Please add job description to website

2019-02-11 Thread Tor Bug Tracker & Wiki
#29176: Please add job description to website
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 hiro: is this done?

 it seems there is a page up:
 https://www.torproject.org/about/jobs-browserdeveloper.html.en

 but this ticket is still open

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

Re: [tor-bugs] #29242 [Webpages/Website]: Please post job description to website (OONI Backend Developer)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29242: Please post job description to website (OONI Backend Developer)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 hiro: is this done?

 it seems there is a page up:
 https://www.torproject.org/about/jobs-backenddeveloper.html.en

 but this ticket is still open

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

[tor-bugs] #29472 [Webpages/Website]: FAQ link on press page is purple-on-purple

2019-02-11 Thread Tor Bug Tracker & Wiki
#29472: FAQ link on press page is purple-on-purple
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On the new page
 https://lektor-staging.torproject.org/tpo/staging/press/
 at the bottom there is a link to FAQ.

 In Tor Browser, hover over the link, and the color of the word FAQ changes
 such that the word disappears. I guess it is turning to purple-on-purple?

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

Re: [tor-bugs] #29297 [Obfuscation/Obfsproxy]: Add any necessary metrics to verify if obfs4 is working or not

2019-02-11 Thread Tor Bug Tracker & Wiki
#29297: Add any necessary metrics to verify if obfs4 is working or not
---+---
 Reporter:  chelseakomlo   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords:  obfs4  |  Actual Points:  2
Parent ID:  #29279 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by gaba):

 * sponsor:   => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29471 [Webpages/Website]: text cleanup on new contact page

2019-02-11 Thread Tor Bug Tracker & Wiki
#29471: text cleanup on new contact page
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Three hopefully simple fixes for
 https://lektor-staging.torproject.org/tpo/staging/contact/

 * "Discuss Tor-related coding, protocols, and ideas are all welcome."
 isn't a sentence. Maybe "Discussion of"? Depends how we want to frame it.

 * "Get Involved" links to "", i.e. it will bring you back to this page.

 * In the gpg --fingerprint output, whoever ran that command should add the
 line "keyid-format long" to their gpg config file and rerun it. That will
 result in 16 hexes for keyid's, not the default 8. This matters in
 practice now since there are fake keys on the keyservers that match in the
 first 8 hexes.

 Lower priority issues:

 * At the top of the page, no part of "Get Support | Need help? Visit our
 Support Portal" is a link. I guess the user is supposed to look at the
 page header and choose 'Support'?

 * At the bottom, where I can pick my language, when I hover over English
 it expands the table, but it expands it *down*, i.e. off the page. I can
 then use down-arrow to go off the purple onto white, which is awkward but
 works.

 * When we point people to lists.torproject.org, that page just presents a
 huge pile of mailing lists, with no organization or hints about which ones
 are popular or useful. We might want to write an interstitial page at some
 point to help users know which lists are worthwhile. We might start from
 https://trac.torproject.org/projects/tor/wiki/doc/emailLists

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

Re: [tor-bugs] #29470 [Applications/Tor Browser]: error message torBrowser-8.0.5-osx6 No Mountable file systems

2019-02-11 Thread Tor Bug Tracker & Wiki
#29470: error message torBrowser-8.0.5-osx6 No Mountable file systems
--+--
 Reporter:  arw54 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:  (none) => tbb-team
 * cc: mcs, brade (added)
 * component:  - Select a component => Applications/Tor Browser


Comment:

 mcs/brade: Any 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

[tor-bugs] #29470 [- Select a component]: error message torBrowser-8.0.5-osx6 No Mountable file systems

2019-02-11 Thread Tor Bug Tracker & Wiki
#29470: error message torBrowser-8.0.5-osx6 No Mountable file systems
+--
 Reporter:  arw54   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  - Select a component
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I keep receiving the above error message when install Tor Browser on iMac
 Pro using 10.14.3. Had no difficulty installing on other Macs with same
 software version. Repeatedly downloaded different versions of browser,
 restarted mac, etc. 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] [Tor Bug Tracker & Wiki] Batch modify: #27399, #26242, #26318, #27539

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #27399, #26242, #26318, #27539 by gk:


Comment:
Move tickets out of TBA-a3 into TBA-stable.

--
Tickets URL: 

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

Re: [tor-bugs] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

2019-02-11 Thread Tor Bug Tracker & Wiki
#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 Replying to [comment:2 nickm]:
 > mikeperry, is this the kind of thing that pathbias is meant to solve?

 If we want the path bias system to check for cases like this, it would not
 be to hard to augment it to send periodic end-to-end probes for introduce1
 circuits, fwiw. We should consider if we want to to that for other
 circuits too.

 I was hopeful that Proposal 295 (or 261 or similar) would allow us to
 remove the path bias code, as crypto tagging attacks would be prevented by
 that. However, circuit choking attacks would not be; we would need
 liveness probes to detect them. End-to-end liveness probes might also help
 with conflux (to more quickly detect when a circuit branch has collapsed
 to build another path).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29469 [Webpages/Website]: Broken verify signature link

2019-02-11 Thread Tor Bug Tracker & Wiki
#29469: Broken verify signature link
--+--
 Reporter:  tom   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://lektor-staging.torproject.org/tpo/staging/download/

 Click Verify Tor Browser signature here. -> broken link

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

Re: [tor-bugs] #29174 [Core Tor/Tor]: Guard Node can eclipse the hidden service

2019-02-11 Thread Tor Bug Tracker & Wiki
#29174: Guard Node can eclipse the hidden service
---+
 Reporter:  TBD.Chen   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.0.1-alpha
 Severity:  Critical   | Resolution:
 Keywords:  guard, hidden service  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 Interesting. This is another argument for Proposal 291 in my mind. A
 single guard has too much power to induce DoS and other downtime signals
 like this. The vanguards addon should similarly mitigate this attack, as
 it uses 2 guards by default. The malicious guard would just cause
 introduce1 timeouts on clients, but not be able to mount a full "eclipse"
 DoS attack.

 As for path bias -- it was designed to detect circuit failures caused by
 the guard. This case is different because the circuit can become live and
 successfully used for one or more initial introduce1 cells, and thus path
 bias system will deem it successfully used. After that point, there is no
 way for a client to determine if the circuit has just gone quiet because
 no one is using the HS vs the guard simply not sending any more introduce1
 cells on the circuit.

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

Re: [tor-bugs] #24347 [Core Tor/Tor]: periodic network bw pattern in an exit relay

2019-02-11 Thread Tor Bug Tracker & Wiki
#24347: periodic network bw pattern in an exit relay
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by toralf):

 see ticket 20849 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] #29145 [Core Tor/Tor]: Fix a compiler warning on OpenBSD in test-memwipe.c

2019-02-11 Thread Tor Bug Tracker & Wiki
#29145: Fix a compiler warning on OpenBSD in test-memwipe.c
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  ahf   |Sponsor:
--+

Comment (by ahf):

 Replying to [comment:6 kjak]:
 > And ugh, yeah, I should have provided some more details in the ticket
 description.  Sorry about that!

 No worries at all. The Tor "network team" is usually good at catching
 warnings on Linux, Windows, and FreeBSD, so we are always very happy when
 people catches issues on other operating systems. Thanks a lot for
 contributing to 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] #28091 [Applications/GetTor]: Port GetTor to python3

2019-02-11 Thread Tor Bug Tracker & Wiki
#28091: Port GetTor to python3
-+
 Reporter:  traumschule  |  Owner:  traumschule
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor   |  Actual Points:
Parent ID:  #28152   | Points:
 Reviewer:  nickm|Sponsor:  Sponsor19
-+
Changes (by nickm):

 * status:  needs_review => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29468 [Webpages/Website]: Broken link: "Verify Tor Browser signature here"

2019-02-11 Thread Tor Bug Tracker & Wiki
#29468: Broken link: "Verify Tor Browser signature here"
--+--
 Reporter:  intrigeri |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 On https://lektor-staging.torproject.org/tpo/staging/download/ links to
 https://support.torproject.org/how-to-verify-signature and I get a 404
 error.

 (Current Tor Browser stable, Debian.)

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

Re: [tor-bugs] #28119 [Applications/Tor Browser]: Provide Tor Browser for Android for arm64-v8a devices

2019-02-11 Thread Tor Bug Tracker & Wiki
#28119: Provide Tor Browser for Android for arm64-v8a devices
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201902, GeorgKoppen201902|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:5 sisbell]:
 > Replying to [comment:4 gk]:
 > > We need to provide 64bit .apks by August this year for Google App
 Store which is why I gave this a shot. `bug_28119`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/log/?h=bug_28119) is the result. It gives me an .apk \o/ There
 is at least the Orbot piece missing, though, as it seems there is no
 aarch64 Orbot support yet. sisbell: How much of the Orbot stuff do we care
 here? I am wondering how much time I should spend fixing this up.
 >
 > Current Android devices will provide a backwards compatibility for 32
 bit versions. What we can't do is mix and match libraries. Once you
 include one arm64-v8a library, all libraries will need to be compiled for
 arm64, otherwise a link error will be thrown.
 >
 > So the Orbot piece would be required:
 > 1) if you include any other arm64 library in the project OR
 > 2) we attempt to upload to Google Play after July of this year
 >
 > Otherwise it will run just fine on 64 bit devices.

 Yes. My question was more like, what do we need from the Orbot stuff we
 ship now after TOPL is used instead because I was wondering how much time
 I should spend on fixing the Orbot stuff.

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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

2019-02-11 Thread Tor Bug Tracker & Wiki
#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by QZw2aBQoPyuEVXYVlBps):

 * Attachment "MemoryMediaCache4.patch" added.


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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

2019-02-11 Thread Tor Bug Tracker & Wiki
#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by QZw2aBQoPyuEVXYVlBps):

 Replying to [comment:23 cypherpunks]:
 > If you want a more sane solution and not "sane" - do not touch that
 Mozilla's `if` code block, it's not broken. Add your own `if
 (aIsPrivateBrowsing)` after it. Never use `int64_t` for something with
 `size` in its name. Never use `int64_t()` in C++. Use spellchecker. What
 happens when you `return nullptr;`?
 We either use their if or copy their code to our own if, I think reusing
 their if is better than code duplication. We want to same exact logic to
 handle either case, so it makes sense to use that block. `int64_t` is what
 Mozilla uses, I'm just following their code. I tested what happened on
 `nullptr` return above, see comment 10.

 The next patch includes the preference changes, I removed the
 `media.cache_size` preference override and added one for
 `media.memory_cache_max_size`, doubling the default value.

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

Re: [tor-bugs] #29283 [Obfuscation/Pluggable transport]: Make PTs go dormant

2019-02-11 Thread Tor Bug Tracker & Wiki
#29283: Make PTs go dormant
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---

Comment (by kat5):

 Possibly related: #28849

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

Re: [tor-bugs] #28119 [Applications/Tor Browser]: Provide Tor Browser for Android for arm64-v8a devices

2019-02-11 Thread Tor Bug Tracker & Wiki
#28119: Provide Tor Browser for Android for arm64-v8a devices
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201902, GeorgKoppen201902|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:4 gk]:
 > We need to provide 64bit .apks by August this year for Google App Store
 which is why I gave this a shot. `bug_28119`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/log/?h=bug_28119) is the result. It gives me an .apk \o/ There
 is at least the Orbot piece missing, though, as it seems there is no
 aarch64 Orbot support yet. sisbell: How much of the Orbot stuff do we care
 here? I am wondering how much time I should spend fixing this up.

 Current Android devices will provide a backwards compatibility for 32 bit
 versions. What we can't do is mix and match libraries. Once you include
 one arm64-v8a library, all libraries will need to be compiled for arm64,
 otherwise a link error will be thrown.

 So the Orbot piece would be required:
 1) if you include any other arm64 library in the project OR
 2) we attempt to upload to Google Play after July of this year

 Otherwise it will run just fine on 64 bit devices.

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

Re: [tor-bugs] #29145 [Core Tor/Tor]: Fix a compiler warning on OpenBSD in test-memwipe.c

2019-02-11 Thread Tor Bug Tracker & Wiki
#29145: Fix a compiler warning on OpenBSD in test-memwipe.c
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  ahf   |Sponsor:
--+

Comment (by kjak):

 Great.  Thanks for reviewing.

 And ugh, yeah, I should have provided some more details in the ticket
 description.  Sorry about that!

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

2019-02-11 Thread Tor Bug Tracker & Wiki
#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:27 dunqan]:
 > Hey everyone,
 >
 > Antonela asked me to review the designs above. I'm not as knowledgeable
 about TBA & Orbot as most of the people in this thread though, so please
 take these recommendations with a pinch of salt!

 Thanks for the feedback!

 >
 > Firstly I agree with everyone who's suggested that the connection (and
 bridging) should happen automatically without requiring any input from the
 user. However the following review assumes there's a good reason for
 requiring manual prompts, since it seems to be the route we've gone down!

 This is a long-standing/outstanding question we have. In the general case,
 we can likely start connecting automatically. But there are some
 situations where that may put the person in harm's way, and we don't know
 in which situation we're operating, so we default to being safer.

 >
 > == 1.0 (Start screen) ==
 >  * Is there enough affordance in the settings cog as an icon alone, or
 should we be presenting users with two clear options instead?

 This is an interesting question. In my testing on a physical device, I'm
 finding it difficult to press the settings cog because it is a little
 small. This wasn't apparent when I was testing with an emulator. I think
 I'll make the settings cog larger or maybe we should consider using a
 different button. I like the existing design, I think it's more
 aesthetically pleasing than showing multiple large buttons.

 >
 >
 > == 2.0 (Bootstrapping) ==
 >  * Should the settings icon be accessible from here at all, since it's a
 transitionary screen with a process already underway?

 I think this is helpful. Pressing that button would effectively cancel the
 current process and restart the bootstrapping process after the person
 changes the settings and returns to this screen.

 >  * Increasing the contrast of "Swipe ~~to~~ left to see Tor log" will
 greatly help our visually impaired users (also note the wee typo in there
 too).

 Yep, I saw that too :)
 >  * Do we need a link to cancel this process in case it hangs? Or provide
 a back button to screen 1.0?

 Ideally, we'll detect when the process hangs and we automatically bring
 the user to the settings screen so they can change the configuration
 (assuming they know what they should do such that it'll work).

 >
 > == 3.0 (Network) ==
 >  * Are users knowledgeable enough to understand that censorship in their
 location is responsible for Tor's failure to connect?

 Right. This is a hard problem. Tor Browser *should* know and be smart
 about how it handles connection failures. Unfortunately, we don't have
 that information at this time, so currently we put the burden on the user.
 Hopefully this will improve in the future.

 >  * It may not be obvious enough to the user that the browser has
 successfully connected after hitting the switch, as the success state is
 quite subtle.
 >  * Users may not understand that they need to hit the back button to
 continue (which seems a little counter-intuitive), and could erroneously
 hit "Change" instead.

 Yes, I agree, my implementation of this takes this into account. I used
 the switch (enabling) as a button. If the switch is currently disabled,
 and the user presses the switch, then bridges becomes enabled and it
 instantly moves to the next Bridge configuration screen. If the user
 returns to this screen after configuring bridges (so the switch is
 currently enabled), and they press the switch again so it becomes
 disabled, then the bridges are disabled and the user is returned to the
 first bootstrapping screen.

 >

 >
 > == 4.0 (Combined Network/Bridge proposal) ==
 > It's my understanding that there are basically three mutually exclusive
 options on the table for when Tor's blocked:
 >
 >  1. Automatic selection
 >  1. Select from list
 >  1. Enter manually
 >
 > So with that in mind, I've wireframed a proposal that combines both the
 "Network" and "Select a bridge" screens into a single menu to:
 >
 >  * Help address any ambiguity about censorship in the UI
 >  * Reduce 

Re: [tor-bugs] #29269 [Obfuscation/BridgeDB]: Evaluation of bridge statistics

2019-02-11 Thread Tor Bug Tracker & Wiki
#29269: Evaluation of bridge statistics
--+---
 Reporter:  cohosh|  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridges, statistics   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+---
Changes (by nickm):

 * status:  new => accepted
 * owner:  sysrqb => nickm


Comment:

 I'm tapped to do the part about evaluating what we have, but somebody else
 would need to assess what we need.

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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

2019-02-11 Thread Tor Bug Tracker & Wiki
#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 If you want a more sane solution and not "sane" - do not touch that
 Mozilla's `if` code block, it's not broken. Add your own `if
 (aIsPrivateBrowsing)` after it. Never use `int64_t` for something with
 `size` in its name. Never use `int64_t()` in C++. Use spellchecker. What
 happens when you `return nullptr;`?

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

2019-02-11 Thread Tor Bug Tracker & Wiki
#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, easy, intro,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by neel):

 * cc: neel (added)
 * owner:  (none) => neel
 * status:  new => assigned


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

Re: [tor-bugs] #29424 [Webpages/Styleguide]: Differentiate between internal and external links

2019-02-11 Thread Tor Bug Tracker & Wiki
#29424: Differentiate between internal and external links
-+--
 Reporter:  irl  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 The idea was to do something consistent across the whole Tor web presence.
 The _blank thing is bad for a lot of reasons, but I'm not sure what the
 best practice "right" thing is to do. We would apply this as part of the
 Bootstrap 4 update once it is integrated to the styleguide.

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

Re: [tor-bugs] #29448 [Obfuscation/BridgeDB]: Provide a dir-spec implementation that serves sanitised descriptors

2019-02-11 Thread Tor Bug Tracker & Wiki
#29448: Provide a dir-spec implementation that serves sanitised descriptors
--+---
 Reporter:  irl   |  Owner:  sysrqb
 Type:  project   | Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by irl):

 Is it currently possible for someone to operate their own CollecTor
 instance and archive bridge descriptors? The answer is no unless they are
 syncing from our CollecTor instance.

 We have access to bridge IPs, which is sensitive information, regardless
 of whether or not we publish that information. This is a violation of not
 handling sensitive information.

 > So, the goal here is basically to extract the sanitizing code from
 CollecTor and put it on the BridgeDB host, probably rewritten in a
 different language. Right?

 Yes.

 > However, I can also see the downsides: code complexity of BridgeDB will
 suddenly increase, and whoever runs BridgeDB has one more complex thing to
 take care of.

 We do get the benefit that we no longer have to handle bridge IPs and
 things are more reproducible. It is also easier for people to run testing
 BridgeDBs with a testing CollecTor instance. It is also easier for people
 to run their own production BridgeDBs that we can see statistics of (which
 is a goal that has been previously discussed, to reduce reliance on the
 single BridgeDB instance and allow orgs to set up their own).

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

Re: [tor-bugs] #29145 [Core Tor/Tor]: Fix a compiler warning on OpenBSD in test-memwipe.c

2019-02-11 Thread Tor Bug Tracker & Wiki
#29145: Fix a compiler warning on OpenBSD in test-memwipe.c
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  ahf   |Sponsor:
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM. For the merger: I had to look up why this symbol needs global
 linkage instead of just static linkage. You can see the documentation for
 these flags at https://man.openbsd.org/malloc#MALLOC_OPTIONS

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

Re: [tor-bugs] #22180 [Internal Services/Service - trac]: trac still sends email to deleted accounts?

2019-02-11 Thread Tor Bug Tracker & Wiki
#22180: trac still sends email to deleted accounts?
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by qbi):

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


Comment:

 Please provide more information. Especially the username is important to
 investigate into this 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] #20319 [Internal Services/Tor Sysadmin Team]: set HPKP headers on onionoo

2019-02-11 Thread Tor Bug Tracker & Wiki
#20319: set HPKP headers on onionoo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by qbi):

 Google Chrome is about to remove it from their next releases:
 https://www.chromestatus.com/feature/5903385005916160
 and HKPK has a quite low adoption rate. So I wonder if we should close it
 as wontfix. What do others think?

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

[tor-bugs] #29467 [Applications/Tor Browser]: Revert fix for #29182 and backport upstream arc4random_buf fix

2019-02-11 Thread Tor Bug Tracker & Wiki
#29467: Revert fix for #29182 and backport upstream arc4random_buf fix
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201902,
 Severity:  Normal   |  GeorgKoppen201902, TBA-a3
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should use https://hg.mozilla.org/mozilla-central/rev/57664c81a1de
 instead of disabling `arc4rdandom_buf` for our Android builds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29161, #29145, #29067, #29060, ...

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #29161, #29145, #29067, #29060, #28623 by dgoulet:
reviewer to ahf

Comment:
(Mistake while assigning. These should go to ahf as a Reviewer.)

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29064, #29073, #29144, #29196, ...

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #29064, #29073, #29144, #29196, #29299 by dgoulet:
reviewer to catalyst

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #27854, #29063, #29072, #29391

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #27854, #29063, #29072, #29391 by dgoulet:
reviewer to dgoulet

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29023, #29062, #29071, #29199, ...

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #29023, #29062, #29071, #29199, #29295 by dgoulet:
reviewer to asn

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #28698, #29065, #29435, #29436

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #28698, #29065, #29435, #29436 by dgoulet:
reviewer to mikeperry

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #28623, #29060, #29067, #29145, ...

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #28623, #29060, #29067, #29145, #29161 by dgoulet:
reviewer to teor

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #25110, #28816, #29061, #29068, ...

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #25110, #28816, #29061, #29068, #29160 by dgoulet:
reviewer to nickm

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #13221, #22029, #29059, #29294

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #13221, #22029, #29059, #29294 by dgoulet:
reviewer to teor

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] #29466 [Metrics/Analysis]: Perform one-off page load time metrics using Tor Browser

2019-02-11 Thread Tor Bug Tracker & Wiki
#29466: Perform one-off page load time metrics using Tor Browser
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  8 |   Reviewer:
  Sponsor:|
--+--
 OnionPerf gives us some idea of network performance as seen by end-users
 for bulk transfer, but that is not the typical traffic on the Tor network.
 Using Tor Browser we can collect page load time metrics and compare with a
 direct connection to compare and contrast.

 This should help to identify bottlenecks, which may be widened through
 either engineering work on the browser, core tor, or by providing advice
 to web developers that have Tor users.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #5830, #6369

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #5830, #6369 by irl:
points to 1
component to Webpages/Research

Action: leave

Comment:
This is to be added as a research idea to the portal and moved out of Trac.

--
Tickets URL: 
Tor Bug Tracker & Wiki 
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] #29465 [Webpages/Research]: Build a torbib

2019-02-11 Thread Tor Bug Tracker & Wiki
#29465: Build a torbib
---+-
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal |   Keywords:  metrics-roadmap-2019-q2
Actual Points: |  Parent ID:
   Points:  2  |   Reviewer:
  Sponsor: |
---+-
 This is a subset of anonbib that would then be maintained by the Tor
 research team as part of research-web.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #6473, #16520, #16659, #29281

2019-02-11 Thread Tor Bug Tracker & Wiki
Batch modification to #6473, #16520, #16659, #29281 by irl:
points to 1

Action: reassign

--
Tickets URL: 

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

Re: [tor-bugs] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

2019-02-11 Thread Tor Bug Tracker & Wiki
#29425: Write integration tests for data-processing modules
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-roadmap-2019-q2
 * points:   => 8


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29464 [Metrics/Relay Search]: Make a how-to video for using Relay Search

2019-02-11 Thread Tor Bug Tracker & Wiki
#29464: Make a how-to video for using Relay Search
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Requested by a relay operator at FOSDEM.

 Using the aggregated search and building search queries is not exactly
 obvious.

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

Re: [tor-bugs] #29235 [Applications/Tor Browser]: Build of https-everywhere fails because python3.6 is not available in buster anymore

2019-02-11 Thread Tor Bug Tracker & Wiki
#29235: Build of https-everywhere fails because python3.6 is not available in
buster anymore
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorBrowserTeam201901R, tbb-rbm  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Applied to `maint-8.0` (commit d036a293dcd041d3ed4d02453b85aa03cfed23fa).

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

Re: [tor-bugs] #29181 [Applications/Tor Browser]: Make it possible to force rebuild of debootstrap-image

2019-02-11 Thread Tor Bug Tracker & Wiki
#29181: Make it possible to force rebuild of debootstrap-image
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201901R, tbb-rbm,  |  Actual Points:
  tbb-backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201901R, tbb-rbm => TorBrowserTeam201901R, tbb-
 rbm, tbb-backported


Comment:

 The fix for this ticket got backported to `maint-8.0` in commit
 1224c208e61b18dfd078f98e88bc1666800cf5bb.

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

Re: [tor-bugs] #29158 [Applications/Tor Browser]: Add fix for DSA 4371-1 (apt vulnerability)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29158: Add fix for DSA 4371-1 (apt vulnerability)
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201901R, tbb-rbm,  |  Actual Points:
  tbb-backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201901R, tbb-rbm => TorBrowserTeam201901R, tbb-
 rbm, tbb-backported


Comment:

 Thanks, looks good to me and pushed to `maint-8.0`. I'll note the commits
 in the respective bugs. The bugfix for this ticket is available in commit
 528f683266709865780e75b14755715f44f04d5a.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29463 [Metrics/Analysis]: Prepare slides for PEARG meeting (IETF 104, March 2019)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29463: Prepare slides for PEARG meeting (IETF 104, March 2019)
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:  metrics-outreach
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Need to update the Internet Draft (https://datatracker.ietf.org/doc/draft-
 learmonth-pearg-safe-internet-measurement/) and prepare a slide deck.

 The schedule is not yet done, but details of the meeting will appear at:

 https://datatracker.ietf.org/rg/pearg/meetings/

 I believe that streaming/recording will be available but can't guarantee
 it.

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

[tor-bugs] #29462 [Metrics/Analysis]: Prepare slides for SCONE meeting (March 2019)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29462: Prepare slides for SCONE meeting (March 2019)
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:  metrics-outreach
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+--
 These will be based on the slides I presented at FOSDEM.

 Meeting details: http://scone.cs.st-andrews.ac.uk/wiki/Meeting12032019

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

Re: [tor-bugs] #29315 [Metrics/Website]: Write down guidelines for adding new stats

2019-02-11 Thread Tor Bug Tracker & Wiki
#29315: Write down guidelines for adding new stats
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-roadmap-2019-q2


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

Re: [tor-bugs] #29315 [Metrics/Website]: Write down guidelines for adding new stats

2019-02-11 Thread Tor Bug Tracker & Wiki
#29315: Write down guidelines for adding new stats
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * priority:  Medium => Very High


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

Re: [tor-bugs] #21378 [Metrics/CollecTor]: Archive bwauth bandwidth files

2019-02-11 Thread Tor Bug Tracker & Wiki
#21378: Archive bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  irl
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * keywords:  tor-bwauth tor-dirauth => tor-bwauth,tor-dirauth,metrics-
 roadmap-2019-q2
 * points:   => 8


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

Re: [tor-bugs] #21315 [Obfuscation/Snowflake]: publish some realtime stats from the broker?

2019-02-11 Thread Tor Bug Tracker & Wiki
#21315: publish some realtime stats from the broker?
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29461 | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

 * cc: metrics-team (added)
 * parent:   => #29461


Comment:

 Metrics Team expects to produce the corresponding CollecTor module for
 this within the next 6-month roadmap.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29461 [Metrics/CollecTor]: Add a Snowflake module

2019-02-11 Thread Tor Bug Tracker & Wiki
#29461: Add a Snowflake module
---+-
 Reporter:  irl|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:  metrics-roadmap-2019-q2
Actual Points: |  Parent ID:
   Points:  8  |   Reviewer:
  Sponsor: |
---+-
 Add a module to CollecTor to archive the statistics produced in #21315.
 The actual statistics and format should be discussed in that ticket. The
 discussion in #29315 may help to inform that.

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

Re: [tor-bugs] #9316 [Obfuscation/BridgeDB]: BridgeDB should export statistics

2019-02-11 Thread Tor Bug Tracker & Wiki
#9316: BridgeDB should export statistics
--+---
 Reporter:  asn   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics,bridgedb  |  Actual Points:
Parent ID:  #19332| Points:  3
 Reviewer:|Sponsor:  Sponsor19
--+---
Changes (by irl):

 * parent:   => #19332


Comment:

 This is required to exist before metrics team can archive them in
 CollecTor.

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

Re: [tor-bugs] #19332 [Metrics/CollecTor]: Add a BridgeDB module (was: Publish BridgeDB stats)

2019-02-11 Thread Tor Bug Tracker & Wiki
#19332: Add a BridgeDB module
-+--
 Reporter:  mrphs|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:  Sponsor19
-+--
Changes (by irl):

 * status:  needs_information => new
 * parent:  #9316 =>
 * cc: ahf, dgoulet, phw (added)
 * points:  1 => 8
 * keywords:  metrics => metrics-roadmap-2019-q2
 * type:  defect => enhancement


Old description:

> While [https://lists.torproject.org/pipermail/tor-
> project/2016-June/000424.html talking about making a PT infographic] and
> interesting stats to point out, asn pointed out that there are no
> publicly available BridgeDB stats.
>
> This can be useful in many different fronts, such as seeing the balance
> between usage and available resources.

New description:

 While [https://lists.torproject.org/pipermail/tor-
 project/2016-June/000424.html talking about making a PT infographic] and
 interesting stats to point out, asn pointed out that there are no publicly
 available BridgeDB stats.

 This can be useful in many different fronts, such as seeing the balance
 between usage and available resources.

 This ticket is about adding a CollecTor module that will archive the stats
 exposed in #9316. The actual stats and format should be discussed in #9316
 and may benefit from the discussion in #29315.

--

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

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

2019-02-11 Thread Tor Bug Tracker & Wiki
#24422: Look at Information Architecture for Tor Metrics
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:  #25404   | Points:  21
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-roadmap-2019-q2
 * points:   => 21


Comment:

 This task includes the data and research portals.

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

Re: [tor-bugs] #28322 [Metrics]: Deploy better notification system for operational issues

2019-02-11 Thread Tor Bug Tracker & Wiki
#28322: Deploy better notification system for operational issues
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-roadmap-2019-q2
 * priority:  Medium => High
 * points:   => 5
 * type:  task => project


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29460 [Metrics]: Get irl up to speed on operations for exonerator

2019-02-11 Thread Tor Bug Tracker & Wiki
#29460: Get irl up to speed on operations for exonerator
-+-
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:  metrics-roadmap-2019-q2
Actual Points:   |  Parent ID:  #28327
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 This will bring us to two operators for this service.

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

Re: [tor-bugs] #28327 [Metrics]: Make sure that each service has at least two operators

2019-02-11 Thread Tor Bug Tracker & Wiki
#28327: Make sure that each service has at least two operators
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-roadmap-2019-q2
 * priority:  Medium => High


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29459 [Metrics/Website]: Get irl up to speed on operations for metrics-web

2019-02-11 Thread Tor Bug Tracker & Wiki
#29459: Get irl up to speed on operations for metrics-web
-+-
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:  metrics-roadmap-2019-q2
Actual Points:   |  Parent ID:  #28327
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 This will give us two operators for this service.

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

Re: [tor-bugs] #29158 [Applications/Tor Browser]: Add fix for DSA 4371-1 (apt vulnerability)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29158: Add fix for DSA 4371-1 (apt vulnerability)
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorBrowserTeam201901R, tbb-rbm  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 Replying to [comment:12 boklm]:
 > In branch `bug_29158_maint-8.0_v2`, I backorted patches for #29158,
 #29181 and #29235 on maint-8.0:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 
build.git/commit/?h=bug_29158_maint-8.0_v2=d036a293dcd041d3ed4d02453b85aa03cfed23fa

 And I checked that a `release` build of `https-everywhere` is working
 correctly.

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

Re: [tor-bugs] #29158 [Applications/Tor Browser]: Add fix for DSA 4371-1 (apt vulnerability)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29158: Add fix for DSA 4371-1 (apt vulnerability)
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorBrowserTeam201901R, tbb-rbm  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 In branch `bug_29158_maint-8.0_v2`, I backorted patches for #29158, #29181
 and #29235 on maint-8.0:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 
build.git/commit/?h=bug_29158_maint-8.0_v2=d036a293dcd041d3ed4d02453b85aa03cfed23fa

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

Re: [tor-bugs] #29149 [Core Tor/sbws]: Update/improve documentation on how the scanner/generator work (was: Document technical overview on how sbws works)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29149: Update/improve documentation on how the scanner/generator work
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---

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

Re: [tor-bugs] #29299 [Core Tor/sbws]: Include scanner country and Web server country in the bandwidth file header

2019-02-11 Thread Tor Bug Tracker & Wiki
#29299: Include scanner country and Web server country in the bandwidth file 
header
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/sbws/pull/335

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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

2019-02-11 Thread Tor Bug Tracker & Wiki
#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:20 QZw2aBQoPyuEVXYVlBps]:
 > Replying to [comment:19 gk]:
 > > You have
 > > {{{
 > >  if (aContentLength < 0) {
 > > }}}
 > > in your patch but looking at the original code I think we should take
 care of the case here as well that `aContentLength` is `0`.
 > If you look here: https://hg.mozilla.org/releases/mozilla-
 
esr60/file/256453759958ed9c2eb17a0764d2fcfd7f8e3323/dom/media/MediaCache.cpp#l153
 > You'll see that `aContentLength` is `-1` if it is unknown, so an
 `aContentLength` of `0` means that's what the server actually sent.

 Yes. I am a bit wary that we are subtly changing the logic here: right now
 in Firefox esr60 a memory-backed media cache is only used if
 `aContentLength` is larger than `0` and less or equal than the max size as
 determined by a pref. Your patch keeps the latter requirement. However, it
 changes the former exposing the memory cache creation to a content length
 of `0`. While this seems okay for now I am a little bit worried that
 Mozilla changes something under the hood which is not affecting them as
 they have the `>` check while we don't exclude the case where
 `aContentLength` is `0`. So, I guess without making your patch even more
 complicated, one way forward would be to take it in the alpha and try to
 upstream it at the same time, so we are sure we won't get surprised by our
 logic change. That's fine with me.

 > > Additionally, I think we should go back to the default size for
 `media.cache_size` so that users outside of private browsing mode get the
 usual behavior (right now they would still be affected by this bug without
 resetting the pref). (https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-
 browser-60.5.0esr-8.5-1 is the file to look at)
 > I agree with this, I was going to mention it but it slipped my mind. I
 also suggested above that the default of `media.memory_cache_max_size`
 should be increased to handle buffering longer media content in memory,
 what do you think about this?

 We could do that. But I'd be cautious here. Maybe let's pick twice as the
 default for now? That should not be worse than the status quo and we
 essentially have not heard about the bug you reported before. So, the
 problem might not be that widespread.

 > > QZw2aBQoPyuEVXYVlBps: Thanks for this find and a patch, really
 appreciated. We are close here. Do you want to fix the remaining things up
 or should we? How should we credit you? (I am fine crediting
 QZw2aBQoPyuEVXYVlBps in the commit message :) )
 > It's a little time consuming for me to test my code since compiling
 takes awhile, but since there's only a few changes, I think I should be
 fine completing it.
 > You can credit either "QZw2aBQoPyuEVXYVlBps" or "anonymous", this is
 simply a throwaway account because I wasn't able to get the cypherpunks
 account to work.

 Okay, let's use "cyperpunk" then. :)

 Thanks for you work here and testing, much appreciated. If you could
 change the pref I am happy to merge the patch and test it wider in an
 upcoming alpha.

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

Re: [tor-bugs] #29417 [Internal Services/Tor Sysadmin Team]: [Nextcloud] Find test group and give them data to work with (was: Find test group and give them data to work with)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29417: [Nextcloud] Find test group and give them data to work with
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #29424 [Webpages/Styleguide]: Differentiate between internal and external links

2019-02-11 Thread Tor Bug Tracker & Wiki
#29424: Differentiate between internal and external links
-+--
 Reporter:  irl  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Happy to change this on the Tor Metrics side if this is bad. I was under
 the impression that it's a good thing, but that impression may be very old
 or very wrong.

 So, right now we're writing external links as:

 {{{
 https://shadow.github.io/; target="_blank">Shadow
 }}}

 I assume we'd remove the target and instead define some class for external
 links and use that for the styling? I can try that if the approach sounds
 sane.

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

Re: [tor-bugs] #29360 [Applications/Tor Browser]: Tor-Browser Linux: no audio playback (pulseaudio)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29360: Tor-Browser Linux: no audio playback (pulseaudio)
--+---
 Reporter:  tries |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:5 tries]:
 > It means:
 > - It did initially work out of the box, but the initial installation was
 quite some time ago with an older version of tor-browser.
 > - Since then, I did online updates (keeping the content of the fake
 HOME)
 > - fresh installation of the current tor-browser fails to produce audio
 (until I copy those pulseaudio files)
 >
 > So I would have to go back in time and figure out what ancient version
 of tor browser was still OK. Unfortunately, the official download location
 does not provide old installation packages - is there an archive
 somewhere? Then I would take the time and check with old versions.

 Thanks! https://archive.torproject.org/tor-package-archive/torbrowser/ has
 all older releases. I guess a good starting point for testing could be
 7.5.6.

 That said on my Linux box sound is fine without having all the hidden
 pulseaudio related folders in my `Browser` directory. So, hrm...

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

Re: [tor-bugs] #29453 [Applications/Tor Browser]: buster-amd64 is missing from debootstrap-image

2019-02-11 Thread Tor Bug Tracker & Wiki
#29453: buster-amd64 is missing from debootstrap-image
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201902R, tbb-rbm,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 Replying to [comment:1 gk]:
 > See: `bug_29453` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_29453=af5f73dc3dc34144736d5f4dfb3134db4f8f652c)
 in my repo for a possible fix.

 This looks good to me. I merged it to master as commit
 af5f73dc3dc34144736d5f4dfb3134db4f8f652c.

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

Re: [tor-bugs] #29455 [Internal Services/Tor Sysadmin Team]: Please update karsten's new PGP subkey

2019-02-11 Thread Tor Bug Tracker & Wiki
#29455: Please update karsten's new PGP subkey
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by ln5):

 * 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] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

2019-02-11 Thread Tor Bug Tracker & Wiki
#27691: reset bootstrap progress when enough things change
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap, 035-deferred-20180930,   |
  bootstrap-arch, 040-deferred-201915|
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by hefee):

 * cc: torproject@… (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] #23605 [Core Tor/Tor]: expired consensus causes guard selection to stall at BOOTSTRAP PROGRESS=80

2019-02-11 Thread Tor Bug Tracker & Wiki
#23605: expired consensus causes guard selection to stall at BOOTSTRAP 
PROGRESS=80
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by hefee):

 * cc: torproject@… (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] #24661 [Core Tor/Tor]: accept a reasonably live consensus for guard selection

2019-02-11 Thread Tor Bug Tracker & Wiki
#24661: accept a reasonably live consensus for guard selection
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, ux, 035   |  Actual Points:
  -backport-maybe, 034-backport-maybe-not, 033   |
  -backport-maybe-not, 033-triage-20180320, 034  |
  -roadmap-proposed, 034-triage-20180328,|
  034-included-20180328, 034-deferred-20180602,  |
  035-removed-20180711   |
Parent ID:  #28018   | Points:  1
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by hefee):

 * cc: torproject@… (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] #28591 [Core Tor/Tor]: Accept a future consensus for bootstrap

2019-02-11 Thread Tor Bug Tracker & Wiki
#28591: Accept a future consensus for bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:  0.5
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711   |
Parent ID:  #28018   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by hefee):

 * cc: torproject@… (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] #29346 [Metrics/Website]: Document why our CSV files are in tidy/long format and how to process them

2019-02-11 Thread Tor Bug Tracker & Wiki
#29346: Document why our CSV files are in tidy/long format and how to process 
them
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by gaba):

 There are other tools (like openrefine) to do pivot table.

 With libreoffice:
 https://schoolofdata.org/handbook/courses/gentle-introduction-exploring-
 and-understanding-data/
 With open refine:
 https://openup.org.za/articles/openrefine-unpivot-tutorial.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] #28355 [Core Tor/sbws]: Disable measurement timing rules on sbws by default

2019-02-11 Thread Tor Bug Tracker & Wiki
#28355: Disable measurement timing rules on sbws by default
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * points:  0.3 => 1
 * milestone:  sbws: 1.0.x-final => sbws: 1.1.x-final


Comment:

 Minimum points is 1. We moved this to milestone 1.1.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29458 [Metrics/Onionperf]: Make sure that op-hk (and the other instances) do not run out of disk space

2019-02-11 Thread Tor Bug Tracker & Wiki
#29458: Make sure that op-hk (and the other instances) do not run out of disk 
space
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Just noticed that op-hk is soon going to run out of disk space. The other
 instances might be affected, too. Not sure if the log archive is the
 primary cause for that, but maybe compressing rotated logs would help.
 (Just don't delete them, please.)

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

Re: [tor-bugs] #29457 [Metrics/Onionperf]: Expose log_archive via the web server (was: Keep tor logs around forever)

2019-02-11 Thread Tor Bug Tracker & Wiki
#29457: Expose log_archive via the web server
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 There are archives of the logs, but they are not currently accessible.

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

Re: [tor-bugs] #27523 [Internal Services/Service - trac]: Restore cypherpunks account for us.

2019-02-11 Thread Tor Bug Tracker & Wiki
#27523: Restore cypherpunks account for us.
--+
 Reporter:  cypherpunks3  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  High  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Critical  | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 cypherpunks is working. If there are parts, which don't work for you,
 please tell us the specific part.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29457 [Metrics/Onionperf]: Keep tor logs around forever

2019-02-11 Thread Tor Bug Tracker & Wiki
#29457: Keep tor logs around forever
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 When I asked hiro last week whether I can take a look at tor logs to
 investigate slow measurements, she told me that these logs are probably
 log-rotated away after a day or so.

 Can we configure our OnionPerf instances in a way that keeps tor logs
 forever? It's okay to log-rotate them daily, but if we can keep them
 around, that might turn out to be very helpful for situations like this.

 If forever is too long from a disk space perspective, how about 1 year or
 at least several months? Info level is probably sufficient.

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

Re: [tor-bugs] #29448 [Obfuscation/BridgeDB]: Provide a dir-spec implementation that serves sanitised descriptors

2019-02-11 Thread Tor Bug Tracker & Wiki
#29448: Provide a dir-spec implementation that serves sanitised descriptors
--+---
 Reporter:  irl   |  Owner:  sysrqb
 Type:  project   | Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by karsten):

 * status:  new => needs_information
 * priority:  Medium => Low


Comment:

 Uhm, wait, we're not violating one of the Tor Metrics principles here. The
 principle we put up is that we're not going to use unpublished data. And
 we're not doing that. We're sanitizing the descriptors before publishing
 them on CollecTor and before processing them in any other of our tools.
 We're not touching the unsanitized bridge descriptors for anything else.

 So, the goal here is basically to extract the sanitizing code from
 CollecTor and put it on the BridgeDB host, probably rewritten in a
 different language. Right?

 I can see the benefits you mentioned. I'm all for removing code from our
 codebase and reducing future maintenance effort!

 However, I can also see the downsides: code complexity of BridgeDB will
 suddenly increase, and whoever runs BridgeDB has one more complex thing to
 take care of. I'd say, given that we're not violating our principles and
 that we didn't plan for this work as part of our roadmap, we should set
 priority to low for now.

 Let's also make sure to coordinate with BridgeDB folks ''before'' somebody
 starts writing new code. Setting to needs_information for that last part.

 By the way, regardless of this specific situation, this is an interesting
 discussion for newly added data in general: where do we sanitize data that
 is too sensitive to be published as is, and who gets to keep that code?
 Let's discuss that more on #29315.

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

Re: [tor-bugs] #27824 [Applications/Tor Browser]: TorBrowser or NoScript 10 prevents cookies even if cookie exceptions are present

2019-02-11 Thread Tor Bug Tracker & Wiki
#27824: TorBrowser or NoScript 10 prevents cookies even if cookie exceptions are
present
+--
 Reporter:  joebt   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  Tor Browser, NoScript, cookies  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Replying to [comment:2 cypherpunks]:
 > It's still not fixed in TBB 8.5.  No time?

 Yep. But we are happy to review and merge patches!

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

  1   2   >