Re: [tor-bugs] #30533 [Core Tor/DirAuth]: Bandwidth Unmeasured in Testing Tor Network

[Tor Bug Tracker & Wiki]

#30533: Bandwidth Unmeasured in Testing Tor Network
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DirAuth |Version:  Tor:
 |  0.3.3.8
 Severity:  Normal   | Resolution:
 Keywords:  Bandwiidth, Testing Tor Network  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by TBD.Chen):

 Replying to [comment:1 nickm]:
 Thank you, I think I really do not run a bandwidth authority. I just run a
 directory authority server in my testing network. Could you give a link to
 show how to run a bandwidth authority? It seems that the manual document
 (https://2019.www.torproject.org/docs/tor-manual-dev.html.en) is not cover
 the bandwidth authority.

 > First off, 0.3.3.8 isn't supported. If it turns out that the problem is
 related to the version, we van't help much.
 >
 > Second, a question: are you running any bandwidth authorities on this
 network?  If not, bandwidth won't get measured.

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

Re: [tor-bugs] #27008 [Internal Services/Service - deb.tpo]: Remove ooniprobe and dependencies

[Tor Bug Tracker & Wiki]

#27008: Remove ooniprobe and dependencies
-+-
 Reporter:  irl  |  Owner:  hellais
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Per the notes in https://lists.torproject.org/pipermail/tor-
 project/2019-May/002331.html the proposed next steps are:

 "Plan: we limp along with ooniprobe in deb.tpo for now, because there
 aren't any better options for users, and then when ooniprobe 3.0 is
 released -- by Nov 2019 is the current schedule -- we remove ooniprobe
 from deb.tpo, point users to the new one and inform existing users how to
 upgrade."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30569 [Applications/Tor Browser]: Add check.torproject.org to about:tor

[Tor Bug Tracker & Wiki]

#30569: Add check.torproject.org to about:tor
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Add check.torproject.org page to about:tor.

 Just a link even if it is not prominent will be good.

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

Re: [tor-bugs] #30559 [Applications/Tor Browser]: Tor won't start up properly

[Tor Bug Tracker & Wiki]

#30559: Tor won't start up properly
--+--
 Reporter:  nicknidzkey   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * owner:  (none) => tbb-team
 * component:  Core Tor => Applications/Tor Browser


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

Re: [tor-bugs] #30428 [Core Tor/Tor]: sendme: Failure to validate authenticated SENDMEs client side

[Tor Bug Tracker & Wiki]

#30428: sendme: Failure to validate authenticated SENDMEs client side
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, sendme, 041-must,   |  Actual Points:
  0411-alpha, postfreeze-ok  |
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by nickm):

 Thanks, I'll review.

 One thing to test as we test -- are we doing this at the correct
 intervals? The tests prove that the intervals _match_ on both sides, but
 not that they match the spec.  One way to verify might be to count how
 much data we have hashed, and make sure that it is the correct number of
 cells, if that makes sense.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30568 [Applications/Tor Browser]: Repair "See Your Security Level" onboarding button

[Tor Bug Tracker & Wiki]

#30568: Repair "See Your Security Level" onboarding button
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 TBB 8.5 update from 8.0.9

 Onboarding dialog, "Security" pane has a grey button, "See Your Security
 Level".  Clicking it opens a 404 Not Found to https://tb-
 manual.torproject.org/security-settings.html

 I guess it was supposed to be https://tb-manual.torproject.org/security-
 settings/

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

Re: [tor-bugs] #30565 [Applications/Tor Browser]: roll back to previous version of TBB - saved logins and tabs lost after tor browser bundle upgrade (8.5)

[Tor Bug Tracker & Wiki]

#30565: roll back to previous version of TBB - saved logins and tabs lost after 
tor
browser bundle upgrade (8.5)
--+--
 Reporter:  rollback-question |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rollback-question):

 the upgraded version is the Tor Browser version 8.5 based on Mozilla
 Firefox 60.7.0esr 64-bit
 running on Linux 64bit

 i have been able to reproduce the same issue on another instance
 (different PC) that also got upgraded today and all saved logins are gone
 there too. let me know if i can provide any more information. i hope this
 is a bug and not a feature!

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

[tor-bugs] #30567 [Applications/Tor Browser]: No way to configure NoScript per tabulator in TorBrowser 8.5

[Tor Bug Tracker & Wiki]

#30567: No way to configure NoScript per tabulator in TorBrowser 8.5
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 There is no way to re-enable the NoScript menu so that JavaScript could be
 enabled per tabulator. At least in the Linux version.
 The design document about the new menu bar mentions, that it should be
 possible for the user to re-enable the NoScript icon manually, but it is
 not.
 The NoScript configuration is only accessible via the AddOns Noscipt
 Preferences, but
  (1) all changes there effect the whole session including reloading all
 tabs - which is a security risk if you do not inspect all tabs before
 doing so
  (2) in the Appearance tab there, it is only possible  to enable the
 NoScript context menu, which seems to be blocked in Tor Browser. No option
 to get the menu button back.

 Without safe way to enable JavaScript for a single tabulator, TorBrowser
 8.5.x is not safe. At least I will fall back to 8.0.9 until this has been
 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] #21483 [Applications/Tor Browser]: DuckDuckGo Onion should be the default instead of DuckDuckGo

[Tor Bug Tracker & Wiki]

#21483: DuckDuckGo Onion should be the default instead of DuckDuckGo
--+--
 Reporter:  lolscreen |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 note: different cypherpunks nym user here than the previous comments.

 is this change planned soon? (or ever?)

 ironically, since any deviation from the defaults makes one's traffic
 unique, choosing to manually select the onion service from the search
 preferences could be argued to reduce one's anonymity

 conversely making the default a dot onion provides a great example of a
 lawful, useful onion 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] #30565 [Applications/Tor Browser]: roll back to previous version of TBB - saved logins and tabs lost after tor browser bundle upgrade (8.5)

[Tor Bug Tracker & Wiki]

#30565: roll back to previous version of TBB - saved logins and tabs lost after 
tor
browser bundle upgrade (8.5)
--+--
 Reporter:  rollback-question |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rollback-question):

 just for clarity, in the preferences the box "Remember logins and
 passwords for websites" is still checked, but the Saved Logins window is
 now empty after the upgrade. saved logins have survived all tor browser
 upgrades for many many years, ever since it exists. also tabs got always
 recovered after a crash (or if the browser got killed) while now they are
 not, even if the settings are the same. something has changed, maybe on
 purpose to make it more secure, but if these settings are forced on me
 i'll have to quit using the browser or just use a vanilla firefox
 connecting to a tor deamon. i understand this is a lot less secure but
 usability is also very important to me

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

Re: [tor-bugs] #30564 [Webpages]: Remove Rose Foundation From Sponsors Page

[Tor Bug Tracker & Wiki]

#30564: Remove Rose Foundation From Sponsors Page
--+
 Reporter:  bekeela   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by bekeela:

Old description:

> Please remove Rose Foundation for Communities and Environment (logo and
> text) from the sponsors page https://www.torproject.org/about/sponsors/
>
> Please add "Rose Foundation for Communities and the Environment - 2018"
> to the Past Sponsors list.

New description:

 Please remove Rose Foundation for Communities and Environment (logo and
 text) from the sponsors page https://www.torproject.org/about/sponsors/

 Please add "Rose Foundation for Communities and the Environment - 2018" to
 the Past Sponsors list. It should link to: https://rosefdn.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

[tor-bugs] #30566 [Webpages/Website]: Update Sponsors page with "Craig Newmark Philanthropies" entry

[Tor Bug Tracker & Wiki]

#30566: Update Sponsors page with "Craig Newmark Philanthropies" entry
--+--
 Reporter:  bekeela   |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Please add "Craig Newmark Philanthropies" to the sponsors list here
 https://www.torproject.org/about/sponsors/

 Logo should come from this page:
 https://craignewmarkphilanthropies.org/newsroom/

 Link should point to https://craignewmarkphilanthropies.org/

 For the description, please use this text:

 Craig Newmark Philanthropies was created by craigslist founder Craig
 Newmark to support and connect people and drive broad civic engagement.
 The organization works to advance people and grassroots organizations that
 are getting stuff done in areas that include trustworthy journalism, voter
 protection, gender diversity in technology, and veterans and military
 families. The organization has provided Tor Project with an unrestricted
 gift.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30565 [Applications/Tor Browser]: roll back to previous version of TBB - saved logins and tabs lost after tor browser bundle upgrade (8.5)

[Tor Bug Tracker & Wiki]

#30565: roll back to previous version of TBB - saved logins and tabs lost after 
tor
browser bundle upgrade (8.5)
---+--
 Reporter:  rollback-question  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications/Tor Browser
  Version:  Tor: unspecified   |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 hi devs,

 i'm not a developer and i don't know how to report bugs. i only know that
 after today's forced (and usually welcome) upgrade of the tor browser
 bundle to version 8.5 all my tabs haven't been recovered and my saved
 logins don't work. this means i can't even access my mail and i lost all
 tabs i had open. i don't want to start a discussion about how insecure it
 is to save passwords or browser history, i just want to have an usable tor
 browser, at this point security is no longer a priority and i'd rather
 have a working insecure browser rather than an unusable secure browser.
 can someone please help me learn how i can roll back to the previous
 version of the tor browser bundle? this is the first time the tor browser
 breaks for me after an upgrade and i'm quite desperate now

 thanks

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

[tor-bugs] #30564 [Webpages]: Remove Rose Foundation From Sponsors Page

[Tor Bug Tracker & Wiki]

#30564: Remove Rose Foundation From Sponsors Page
--+
 Reporter:  bekeela   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Please remove Rose Foundation for Communities and Environment (logo and
 text) from the sponsors page https://www.torproject.org/about/sponsors/

 Please add "Rose Foundation for Communities and the Environment - 2018" to
 the Past Sponsors list.

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

Re: [tor-bugs] #30551 [Applications/Tor Browser]: Android - Use different port numbers

[Tor Bug Tracker & Wiki]

#30551: Android - Use different port numbers
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 Replying to [comment:2 sysrqb]:
 > Replying to [comment:1 sisbell]:
 > > These values are the ones defined by Orbot but we can override them
 for torbrowser.
 > >
 > > We can extend AndroidTorSettings (say BrowserTorSettings) and override
 transPort(), getHttpTunnelPort(), dnsPort() to all return null. This will
 remove them from the generated torrc file so there will not be any
 conflict.
 > >
 > > Then in TorService.onCreate(), we detect if the package name is
 torbrowser and if so use BrowserTorSettings rather than AndroidSettings.
 > >
 >
 > Hmmm, okay, I'll look into this. Thanks! We'll be sad if we must special
 case it based on package name (we have three different packages right now,
 `torbrowser`, `torbrowser_alpha`, `torbrowser_nightly`). And other apps
 may want this capability too.

 We can always remove the default values used in AndroidTorSettings. That
 way if the app doesn't explicitly set them, they won't be added the torrc
 file. We'd just need to make sure that apps like Orbot set default
 preferences explicitly on startup.

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

Re: [tor-bugs] #30551 [Applications/Tor Browser]: Android - Use different port numbers

[Tor Bug Tracker & Wiki]

#30551: Android - Use different port numbers
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:1 sisbell]:
 > These values are the ones defined by Orbot but we can override them for
 torbrowser.
 >
 > We can extend AndroidTorSettings (say BrowserTorSettings) and override
 transPort(), getHttpTunnelPort(), dnsPort() to all return null. This will
 remove them from the generated torrc file so there will not be any
 conflict.
 >
 > Then in TorService.onCreate(), we detect if the package name is
 torbrowser and if so use BrowserTorSettings rather than AndroidSettings.
 >

 Hmmm, okay, I'll look into this. Thanks! We'll be sad if we must special
 case it based on package name (we have three different packages right now,
 `torbrowser`, `torbrowser_alpha`, `torbrowser_nightly`). And other apps
 may want this capability 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] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by phw):

 Replying to [comment:8 cohosh]:
 > I think the `timeout` input to
 [https://github.com/NullHypothesis/obfs4PortScan/blob/fix/30472/handlers.go#L70
 isTCPPortReachable] is redudant now.
 [[br]]
 Yes, good catch.
 [[br]]
 > As long as you're not logging IP addresses, this seems fine to me.
 You're also not exporting the data, it's mostly a consideration in the
 case that the machine or service is compromised. I don't see issues with
 an attacker getting ahold of the number of requests made and the times at
 which they are made. There are probably easier ways to find out whatever
 information they would hope to find out from these logs anyway.
 [[br]]
 Yes, agreed.

 Ok, I'll move forward with setting up the service on polyanthum. Thanks
 for the reviews!

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

Re: [tor-bugs] #30284 [Applications/Tor Browser]: start fails with "Control port file not created"

[Tor Bug Tracker & Wiki]

#30284: start fails with "Control port file not created"
-+-
 Reporter:  belm0|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.5-must, TorBrowserTeam201905R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:30 echaskaris]:
 > Replying to [comment:25 gk]:
 > > echaskaris: could you test whether https://github.com/sisbell/tor-
 files/blob/master/orbot-topl-debug.apk is working for you?
 > It works, but orbot always worked.

 Great! Yes, Orbot always worked, but this is a modified version of Orbot
 and this version uses the same piece of code that caused the bug
 originally in Tor Browser. So, if this version of orbot works, then the
 new version of Tor Browser should work.

 Thanks for testing it.

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

Re: [tor-bugs] #30336 [Applications/Tor Browser]: Tor Browser for Android Alpha

[Tor Bug Tracker & Wiki]

#30336: Tor Browser for Android Alpha
--+---
 Reporter:  WinXAnd511|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 Neat bug. I think this should be solved by uninstalling and reinstalling
 the app.

 I'm guessing this happened because the configuration was changed for
 restricting nodes by country code  when we used Orbot's UI originally
 (configuring EntryNodes, ExitNodes, StrictNodes, ExcludeNodes, etc). In
 newer releases, we don't ship the geoip databases, so bootstrapping
 breaks.

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

Re: [tor-bugs] #30563 [Community/Outreach]: adobe.com blocks tor.

[Tor Bug Tracker & Wiki]

#30563: adobe.com blocks tor.
+---
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:  not a bug
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by sysrqb):

 * component:  - Select a component => Community/Outreach


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

Re: [tor-bugs] #30563 [- Select a component]: adobe.com blocks tor.

[Tor Bug Tracker & Wiki]

#30563: adobe.com blocks tor.
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

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


Comment:

 Unfortunately, this is their choice. Please contact them and ask them not
 to block Tor connections. It looks like they are using Akamai, there is a
 configuration option for this.

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

[tor-bugs] #30563 [- Select a component]: adobe.com blocks tor.

[Tor Bug Tracker & Wiki]

#30563: adobe.com blocks tor.
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I notice that adobe is blocking access from tor. Please look into it.

 Access Denied
 You don't have permission to access "http://www.adobe.com/; on this
 server.

 Reference #18.a9b31bb8.1558471374.167a1a0e

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

Re: [tor-bugs] #30541 [Applications/Tor Browser]: webgl readPixels FP entropy

[Tor Bug Tracker & Wiki]

#30541: webgl readPixels FP entropy
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201905R, GeorgKoppen201905   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Replying to [comment:6 cypherpunks]:
 > Also your test shows...webgl2: supported.. But `webgl2` shouldn't be
 allowed.

 Thanks. If the browser reports that webgl2 is supported, that's one bit of
 entropy. I'll double check with some tests and kkapsner (it's his code),
 opened an issue [1]. This is a browser level API check

 What the browser does in a test after that can provide more entropy: e.g
 error entropy (e.g blocked at a different step of the process: e.g slider
 settings, click to play, extension interference, etc), or provide a hash

 Not sure if meant the API check is flawed, or if TB blocks `WebGL2`.

 [1] https://github.com/ghacksuserjs/TorZillaPrint/issues/37

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

Re: [tor-bugs] #30451 [Circumvention/Snowflake]: snowflake-client has executable stack

[Tor Bug Tracker & Wiki]

#30451: snowflake-client has executable stack
-+--
 Reporter:  boklm|  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201905 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 It turns out there's an easier way to handle this by putting the cgo
 directives into an environment variable. I attached a new version of the
 patch to this ticket.

 My reasoning for putting this in `projects/go/config` as opposed to just
 `projects/go-webrtc/config` is that this problem will occur in all go
 projects that use cgo, and it also allows us to use the template build
 script `projects/go/var/build_go_lib` in `go-webrtc`.

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

Re: [tor-bugs] #30451 [Circumvention/Snowflake]: snowflake-client has executable stack

[Tor Bug Tracker & Wiki]

#30451: snowflake-client has executable stack
-+
 Reporter:  boklm|  Owner:  cohosh
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201905 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * Attachment "0001-Compile-go-webrtc-with-a-non-executable-stack.3.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] #30560 [Applications/Tor Browser]: Onboarding toolbar graphic doesn't match actual toolbar after upgrade

[Tor Bug Tracker & Wiki]

#30560: Onboarding toolbar graphic doesn't match actual toolbar after upgrade
+--
 Reporter:  sysrqb  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-onboarding, tbb-8.5-issues  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 Replying to [comment:5 gk]:
 > It might even be confusing for users that still have an old Tor Browser
 that originally shipped with the search bar and just used the internal
 updater every time until 8.5 now.

 And this is my situation.

 > Still, I am not sure how we can know what the user's toolbar layout
 looks like and show the respective image. Or maybe, on second thought, the
 onboarding logic could actually figure that out and show the proper image
 out of, say, three scenarios we would take care of? But then again, that's
 quite some work to do. :)

 Yes, I don't claim I have the correct answer :) Maybe a different graphic
 showing the awesomebar and the new shield+onion icons instead of the
 current one showing the corner of the browser with "a textbox" and the
 three buttons? I'm imagining moving the focus of the graphic from the
 corner of the browser window to the awesomebar and onion+shield buttons. I
 don't know if this makes sense, 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] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 Replying to [comment:7 phw]:
 > Replying to [comment:6 cohosh]:
 > > - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
 > >  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 > [[br]]
 > Good point, fixed in the following branch:
 https://github.com/NullHypothesis/obfs4PortScan/tree/fix/30472
 I think the `timeout` input to
 [https://github.com/NullHypothesis/obfs4PortScan/blob/fix/30472/handlers.go#L70
 isTCPPortReachable] is redudant now.
 > [[br]]
 > > - Do you also want timestamps in your logs?
 > [[br]]
 > I would like to keep timestamps because they tell us how much (ab)use
 the service is seeing. Do you see any issues with timestamps?
 >
 As long as you're not logging IP addresses, this seems fine to me. You're
 also not exporting the data, it's mostly a consideration in the case that
 the machine or service is compromised. I don't see issues with an attacker
 getting ahold of the number of requests made and the times at which they
 are made. There are probably easier ways to find out whatever information
 they would hope to find out from these logs anyway.
 > On a related note: I noticed that the http package can log error
 messages that include the client's IP address. I included snowflake's safe
 logger to prevent this from happening.
 > [[br]]
 Oh good point, I'm glad the package is useful here.

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: Onboarding toolbar graphic doesn't match actual toolbar after upgrade

[Tor Bug Tracker & Wiki]

#30560: Onboarding toolbar graphic doesn't match actual toolbar after upgrade
+--
 Reporter:  sysrqb  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-onboarding, tbb-8.5-issues  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:   => tbb-onboarding, tbb-8.5-issues
 * cc: mcs, brade (added)


Comment:

 Replying to [comment:2 sysrqb]:
 > yes, that is understandable - so the new toolbar layout is only used in
 new installations because we don't want to modify any customizations. I'm
 more concerned about the onboarding graphic not matching the real toolbar.
 I don't know how that should be corrected. Maybe deleting the hamburger
 icon will help? After I looked at that graphic, then I looked up at the
 hamburger icon and expected to see the onion and shield icons there - but
 they weren't there. They were on the other side of the search box. I found
 this confusing.

 Yes, it is. The logic says the icons get inserted after the URL bar. So,
 given we have only one image showing the new icons during the onboarding,
 what we did was taking a vanilla Tor Browser 8 as we ship it and go from
 that one. That might get confusing for users who customized their toolbar
 and added the search box, yes. It might even be confusing for users that
 still have an old Tor Browser that originally shipped with the search bar
 and just used the internal updater every time until 8.5 now. Still, I am
 not sure how we can know what the user's toolbar layout looks like and
 show the respective image. Or maybe, on second thought, the onboarding
 logic could actually figure that out and show the proper image out of,
 say, three scenarios we would take care of? But then again, that's quite
 some work to do. :)

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: Onboarding toolbar graphic doesn't match actual toolbar after upgrade (was: Onboarding toolbar graphic doesn't match actual toolbar after uprgade)

[Tor Bug Tracker & Wiki]

#30560: Onboarding toolbar graphic doesn't match actual toolbar after upgrade
--+--
 Reporter:  sysrqb|  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:
--+--

Comment (by sysrqb):

 and typo.

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

Re: [tor-bugs] #30561 [Core Tor/Tor]: Fixed tor_vasprintf on systems without vasprintf.

[Tor Bug Tracker & Wiki]

#30561: Fixed tor_vasprintf on systems without vasprintf.
--+--
 Reporter:  paldium   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * milestone:   => Tor: unspecified


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

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

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  irl  |Sponsor:  Sponsor19
-+
Changes (by cohosh):

 * cc: dcf, arlolra (added)


Comment:

 I've cc'd dcf and arlolra to see if they have thoughts on this.

 I just thought of another thing that makes snowflake quite different from
 relays or bridges is the expected amount of time that each proxy will be
 online. It might make more sense to shorten the collection period from 24
 hours in this case. Another thing we can do is have the broker export
 another metric that includes something like the average amount of time a
 unique proxy was available.

 Also noting that mapping unique proxies to IP addresses isn't quite how
 snowflake is supposed to work: we'll probably want some kind of persistent
 identifier later as mentioned in the comments above, but I think it will
 work fine for our purposes now.

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

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

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
-+
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29461   | Points:
 Reviewer:  irl  |Sponsor:  Sponsor19
-+

Comment (by cohosh):

 Replying to [comment:14 irl]:
 Thanks for this feedback. This was very helpful. What makes snowflake
 statistics a little more complex than bridge or relay stats is that, while
 stats about how many times a bridge was used doesn't closely reflect
 client usage, proxies handle either a single client or a small, fixed
 number of clients as determined by the individual proxy and so there's a
 greater possibility for data leakage there.
 > Number of currently available snowflake proxies is not sensitive. We do
 not make any efforts to hide the numbers of relays or bridges, and so this
 can be an exact count. The question here is not the count resolution but
 the time resolution. (Sorry to answer your question with a question.)
 >
 > If I'm an attacker, can I learn anything about a client if I can observe
 the client's traffic and the exact count of snowflakes. For example, what
 do I learn if a snowflake that a client is using disappears? I'm not sure
 what the snowflake protocol does in this case.
 Possibly, as stated above, it depends on what type of proxy you are and
 how it's set up. I think we're better off doing binning in this case.
 However, as stated below, if we collect at a granularity of every 24 hours
 this shouldn't leak client usage.
 >
 > I'm not sure what you mean with the GeoIP stats. If these are stats
 regarding the locations of proxies, again exact counts would be fine and
 would be in line with what we do for relays and bridges at the moment. If
 this is for clients, we should aim to provide differential privacy. I fear
 that at the moment, we are not seeing enough users that we can safely
 report GeoIP stats (usefully) for clients at all. With relays and bridges,
 we round the counts up to the nearest multiple of 8.
 We're absolutely not collecting geoip stats of clients. These are only of
 snowflake proxies. I originally thought to include geoip stats of proxies
 that are actually handed out but it's safer to do stats for available
 proxies since this shouldn't leak client usage if collected over a period
 of 24 hours.
 >
 > Round trip time of snowflake rendezvous sounds like a really useful
 metric for engineering work, but a dangerous one for safety. This would be
 a good candidate for PrivCount but without such a technique I wouldn't do
 this one. We currently measure performance of relays using active
 measurement, such that we are only analyzing our own traffic. We have
 extended that tool, OnionPerf, to also work for pluggable transports but
 it will do the end-to-end performance not just client->snowflake.
 >
 That's fair, this is really only available for debug purposes. We don't
 need to export it as a metric and I'd argue that this should only be
 logged locally.
 > Can you lay out in detail exactly what metrics you'd want, what
 resolution data you want (both in counts and in time) and what you might
 consider an attacker could learn, assuming they are in a position to
 monitor, or are running, a point in the network?
 >
 It looks like bridge stats default to 24 hours, that seems reasonable for
 snowflake as well.
 > Section 2.1.2 of dir-spec contains some examples of descriptions of
 metrics.

 To summarize, and be more precise about what we want to collect, I've put
 our proposed exported metrics in the Tor Directory Protocol Format:
 {{{
 "snowflake-stats-end" -MM-DD HH:MM:SS (NSEC s) NL
 [At most once.]

 -MM-DD HH:MM:SS defines the end of the included measurement
 interval of length NSEC seconds (86400 seconds by default).

 "snowflake-ips" CC=NUM,CC=NUM,... NL
 [At most once.]

 List of mappings from two-letter country codes to the number of
 unique IP addresses of available snowflake proxies, rounded up
 to the nearest multiple of 8.

 "snowflake-available-count" NUM
 [At most once.]

 A count of the number of unique IP addresses corresponding
 to currently available snowflake proxies, rounded up to
 the nearest multiple of 8.

 "snowflake-usage-count" NUM
 [At most once.]

 A count of the number of snowflake proxies that have been
 handed out by the broker to clients, rounded up to the
 nearest multiple of 8.

 }}}

 So in short, we'd collect 

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by phw):

 Replying to [comment:6 cohosh]:
 > - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
 >  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 [[br]]
 Good point, fixed in the following branch:
 https://github.com/NullHypothesis/obfs4PortScan/tree/fix/30472
 [[br]]
 > - In `main()` you could have the certificate and key files passed in as
 specific arguments such as `--cert` or `--key` as the broker does
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage
 of this is making sure they are passed in the correct order (which should
 be documented outside of the usage function).
 [[br]]
 Also fixed in the same branch.
 [[br]]
 > - Do you also want timestamps in your logs?
 [[br]]
 I would like to keep timestamps because they tell us how much (ab)use the
 service is seeing. Do you see any issues with timestamps?

 On a related note: I noticed that the http package can log error messages
 that include the client's IP address. I included snowflake's safe logger
 to prevent this from happening.
 [[br]]
 > As a more general note, is this meant to be used in an automated way for
 bridge operators to log and report to themselves when their port isn't
 reachable? Or as an occasional manual check? I know this is something
 temporary so maybe not a large consideration, but returning something
 other than a `200 OK` if the port is unreachable would make it easier to
 write a client-side go program that performs this check automatically.
 [[br]]
 At this point it's meant for occasional manual checks. I plan to add a
 link to the service to our
 
[https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy
 obfs4proxy installation guide]. I originally intended this service to be
 used as an API (see the bottom paragraph of the ticket's description) but
 it's not clear if we want yet another service that deals with bridge data.
 The better way forward may be to improve BridgeDB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30562 [Community/Tor Browser Manual]: https://tb-manual.torproject.org/security-settings.html is not working

[Tor Bug Tracker & Wiki]

#30562: https://tb-manual.torproject.org/security-settings.html is not working
--+-
 Reporter:  boklm |  Owner:  wayward
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In Tor Browser 8.5, in the security level preferences, when clicking on
 "Learn More", a tab is open with the URL https://tb-manual.torproject.org
 /security-settings.html, giving a "404 Not Found" error.

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

Re: [tor-bugs] #30428 [Core Tor/Tor]: sendme: Failure to validate authenticated SENDMEs client side

[Tor Bug Tracker & Wiki]

#30428: sendme: Failure to validate authenticated SENDMEs client side
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, sendme, 041-must,   |  Actual Points:
  0411-alpha, postfreeze-ok  |
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by dgoulet):

 * status:  merge_ready => needs_review


Comment:

 Replying to [comment:12 nickm]:
 > Looks good; how are the tests looking?

 The new very small commit `4ef8470fa5480d3b` actually broke things when I
 tested with the latest chutney `bidi` branch.

 Turns out that we needed that `minus 1` on the window. I explain why in
 the new commit. I've thus reverted `4ef8470fa5480d3b` as well first and
 then new commit:

 {{{
 19c086365957dc93
   sendme: Clarify how sendme_circuit_cell_is_next() works [David Goulet]
 6380a2f307ba8f7b
   Revert "sendme: Off by one on the SENDME window" [David Goulet]
 }}}

 This has been quite tested now just to find that issue that was not
 showing up reliably for unknown reasons on nickm's `bidi` chutney.

 I confirm that the digests matches as expected on both sides.

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: Onboarding toolbar graphic doesn't match actual toolbar after uprgade (was: NoScript and HTTPS-E remain in toolbar)

[Tor Bug Tracker & Wiki]

#30560: Onboarding toolbar graphic doesn't match actual toolbar after uprgade
--+--
 Reporter:  sysrqb|  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:
--+--

Comment (by sysrqb):

 I'll change the title.

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: NoScript and HTTPS-E remain in toolbar

[Tor Bug Tracker & Wiki]

#30560: NoScript and HTTPS-E remain in toolbar
--+--
 Reporter:  sysrqb|  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:
--+--

Comment (by sysrqb):

 yes, that is understandable - so the new toolbar layout is only used in
 new installations because we don't want to modify any customizations. I'm
 more concerned about the onboarding graphic not matching the real toolbar.
 I don't know how that should be corrected. Maybe deleting the hamburger
 icon will help? After I looked at that graphic, then I looked up at the
 hamburger icon and expected to see the onion and shield icons there - but
 they weren't there. They were on the other side of the search box. I found
 this confusing.

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

Re: [tor-bugs] #30511 [Circumvention/Snowflake]: Remove OnIceComplete

[Tor Bug Tracker & Wiki]

#30511: Remove OnIceComplete
-+--
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> This is a follow up from #25688
>
> https://github.com/keroserene/snowflake/compare/ice
>
> https://github.com/keroserene/go-
> webrtc/commit/f0f4f0a1a37c432619370035c0596b8094d6cbe8

New description:

 This is a follow up from #25688

 https://github.com/keroserene/snowflake/compare/ice

 https://github.com/keroserene/go-webrtc/pull/106

--

Comment (by arlolra):

 Replying to [comment:5 cohosh]:
 > Otherwise the patches look good to me.

 Thanks, I merged the snowflake changes in,
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=d7676d2b9e45c957bf39ea2d5662996aeab5b4de
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=5380aaca8c1c789fa4f692e93dfdc4e59d4992af

 For go-webrtc, I wasn't sure if you all looked at that yet and since it's
 a backwards incompatible change, I'll leave some more time.

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: NoScript and HTTPS-E remain in toolbar

[Tor Bug Tracker & Wiki]

#30560: NoScript and HTTPS-E remain in toolbar
--+--
 Reporter:  sysrqb|  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):

 * cc: pospeselr, antonela (added)


Comment:

 Well, the problem here is that the toolbar is essentially user
 customizable as e.g. can be seen on your image with the search bar which
 is not enabled by default in Firefox/Tor Browser. So, what do we do then?
 We made the decision to not mess with the toolbar for installed Tor
 Browser versions, but rather customize it only for new Tor Browsers as we
 want.

 Yes, this leaves the Noscript icon and the HTTPS-Everywhere icon on for
 those users that still have those on the toolbar. I think there is not
 much more we can do here without risking serious interference with user
 customizations. Thus, I am inclined to just live with that and mark this
 as WONTFIX.

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

Re: [tor-bugs] #30561 [Core Tor/Tor]: Fixed tor_vasprintf on systems without vasprintf.

[Tor Bug Tracker & Wiki]

#30561: Fixed tor_vasprintf on systems without vasprintf.
--+--
 Reporter:  paldium   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.5
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by paldium):

 * Attachment "Fixed-tor_vasprintf-on-systems-without-vasprintf.patch"
 added.


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

[tor-bugs] #30561 [Core Tor/Tor]: Fixed tor_vasprintf on systems without vasprintf.

[Tor Bug Tracker & Wiki]

#30561: Fixed tor_vasprintf on systems without vasprintf.
--+--
 Reporter:  paldium   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.0.5  |   Severity:  Minor
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 If tor is compiled on a system with neither vasprintf nor _vscprintf,
 the fallback implementation exposes a logic flaw which prevents
 proper usage of strings longer than 127 characters:

 * tor_vsnprintf returns -1 if supplied buffer is not large enough,
   but tor_vasprintf uses this function to retrieve required length
 * the result of tor_vsnprintf is not properly checked for negative
   return values

 Both aspects together could in theory lead to exposure of uninitialized
 stack memory in the resulting string. This requires an invalid format
 string or data that exceeds integer limitations.

 Fortunately tor is not even able to run with this implementation because
 it runs into asserts early on during startup. Also the unit tests fail
 during a "make check" run.

 At this point it would make sense to check if support for these systems is
 still a desired option. It seems that nobody noticed lack of support for
 at least a year.

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

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 Replying to [comment:4 phw]:
 > I built a small golang service that lets bridge operators test their
 obfs4 port. For now, the code is available at
 https://github.com/NullHypothesis/obfs4PortScan.
 >
 > I set up a demo at https://nymity.ch:8081. After entering your bridge's
 IP address and port, the service tells you if the port is reachable or
 not.  If the port is unreachable, the service tells you the error message
 it got. The tool also has a simple rate limiter that limits requests to an
 average of one per second, with bursts of up to five per second.
 >
 Awesome! It worked for me :)

 I just have a few minor comments:
 - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 - In `main()` you could have the certificate and key files passed in as
 specific arguments such as `--cert` or `--key` as the broker does
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage
 of this is making sure they are passed in the correct order (which should
 be documented outside of the usage function).
 - Do you also want timestamps in your logs?

 As a more general note, is this meant to be used in an automated way for
 bridge operators to log and report to themselves when their port isn't
 reachable? Or as an occasional manual check? I know this is something
 temporary so maybe not a large consideration, but returning something
 other than a `200 OK` if the port is unreachable would make it easier to
 write a client-side go program that performs this check automatically.

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

Re: [tor-bugs] #30560 [Applications/Tor Browser]: NoScript and HTTPS-E remain in toolbar

[Tor Bug Tracker & Wiki]

#30560: NoScript and HTTPS-E remain in toolbar
--+--
 Reporter:  sysrqb|  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 sysrqb):

 * Attachment "TorBrowser85_toolbar.png" added.


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

[tor-bugs] #30560 [Applications/Tor Browser]: NoScript and HTTPS-E remain in toolbar

[Tor Bug Tracker & Wiki]

#30560: NoScript and HTTPS-E remain in toolbar
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 One of my installations just updated to 8.5, but the Onboarding screen
 doesn't match the actual toolbar.

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

Re: [tor-bugs] #29258 [Circumvention/Snowflake]: What is the IPv6 story with Snowflake

[Tor Bug Tracker & Wiki]

#29258: What is the IPv6 story with Snowflake
---+---
 Reporter:  ahf|  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Circumvention/Snowflake|Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  anti-censorship-roadmap-maybe  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by phw):

 * keywords:   => anti-censorship-roadmap-maybe


Comment:

 A brief summary from [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-05-16-17.01.log.html an anti-censorship meeting] in which we
 discussed snowflake and IPv6:
 * Clients already can connect to snowflake proxies over IPv6.
 * Our broker currently has no IPv6 address.
 * We should have a way to ensure that an IPv6-only Tor Browser can use
 snowflake (see #29259).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30559 [Core Tor]: Tor won't start up properly

[Tor Bug Tracker & Wiki]

#30559: Tor won't start up properly
-+--
 Reporter:  nicknidzkey  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Component:  Core Tor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Ever since tor version 8.0.3 i haven't been able to use the application as
 it wont start up to the home page and instead opens two windows in the
 taskbar. Im using toe on win10.

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

Re: [tor-bugs] #30296 [Community/Tor Browser Manual]: Update screenshot at tb-manual.torproject.org/security-settings

[Tor Bug Tracker & Wiki]

#30296: Update screenshot at tb-manual.torproject.org/security-settings
--+--
 Reporter:  wayward   |  Owner:  wayward
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wayward):

 Done - pull request here: https://github.com/andpersand/manual/pull/new
 /sec-settings-screenshots

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

[Tor Bug Tracker & Wiki]

#30558: Namecoin support for onion sites in Tor Browser
--+
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #30029
   Points:|   Reviewer:
  Sponsor:|
--+
 **The problem**
 Onion domains are generally almost impossible for humans to remember.
 Specifically, they are very long and consist of a series of random
 characters.

 v2 domains look like this:
 * https://www.propub3r6espa33w.onion/

 and v3 domains look like this:
 * http://vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion

 So, while onion domains are secure and decentralized, they are not human-
 meaningful, and thus fail to satisfy all three desired properties
 described in [https://en.wikipedia.org/wiki/Zooko%27s_triangle Zooko's
 triangle].

 **Proposed solution**
 Namecoin offers a solution for Zooko's triangle. Domains are registered in
 a decentralized manner, can be remembered by humans, and are secure. A
 Namecoin (.bit) domain looks like this:
 * http://federalistpapers.bit

 The .bit domains can be pointed to a unique .onion domain. So the user
 needs only to enter http://federalistpapers.bit and they will be taken to
 the appropriate onion site (in this case,
 http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion)

 The task consists of writing patches for Tor Browser that integrates a
 Namecoin lookup client, such that when a user enters a .bit domain name
 the browser is connected to the underlying .onion site. In the address
 bar, the entered address including a .bit domain will continue to be
 shown, and the .onion domain will be indicated on the circuit display.

 Initially, the patches can be integrated into Tor Browser Nightly. If
 testing is successful, I hope it could progress to Tor Browser alpha and
 eventually stable.

 ** Comparison to other approaches **
 There are several promising approaches to allowing human-meaningful
 aliases to onion sites. However, they don't fully solve Zooko's triangle:
 * HTTPS Everywhere: Aliases are under central control by the addon
 maintainer.
 * Bookmarks/Petnames: Aliases are not global.
 * Alt-Svc/Onion-Location: Aliases require first connecting through a
 centralized ICANN domain.

 I think Namecoin is especially promising because it can be globally
 registered and maintained securely by the onion site operator, without any
 centralized permission. Thus the properties of security and
 decentralization offered by .onion domains are shared by .bit domains.

 There are some challenges:
 * Historically, Namecoin lookup has been slow and required cumbersome
 downloads. Jeremy has made major progress in reducing the footprint.
 * Registering a Namecoin domain requires downloading specialized software
 and is not anonymous without special precautions. Future work (out of
 scope here) could include building documentation and/or software tools to
 allow onion operators to easily and anonymously register a .bit domain and
 point it to a .onion domain.

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

Re: [tor-bugs] #30551 [Applications/Tor Browser]: Android - Use different port numbers

[Tor Bug Tracker & Wiki]

#30551: Android - Use different port numbers
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sisbell):

 These values are the ones defined by Orbot but we can override them for
 torbrowser.

 We can extend AndroidTorSettings (say BrowserTorSettings) and override
 transPort(), getHttpTunnelPort(), dnsPort() to all return null. This will
 remove them from the generated torrc file so there will not be any
 conflict.

 Then in TorService.onCreate(), we detect if the package name is torbrowser
 and if so use BrowserTorSettings rather than AndroidSettings.

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

Re: [tor-bugs] #28918 [Applications/Tor Browser]: Mobile TorBrowser will not download anything.

[Tor Bug Tracker & Wiki]

#28918: Mobile TorBrowser will not download anything.
--+--
 Reporter:  BoySlides |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  user disappeared
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * status:  needs_information => closed
 * resolution:   => user disappeared


Comment:

 Closing this for now. Please re-open if this is still a problem.

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

Re: [tor-bugs] #30428 [Core Tor/Tor]: sendme: Failure to validate authenticated SENDMEs client side

[Tor Bug Tracker & Wiki]

#30428: sendme: Failure to validate authenticated SENDMEs client side
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, sendme, 041-must,   |  Actual Points:
  0411-alpha, postfreeze-ok  |
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Looks good; how are the tests looking?

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

Re: [tor-bugs] #30557 [Core Tor/Tor]: prop289: Update proposal with new deployment plan

[Tor Bug Tracker & Wiki]

#30557: prop289: Update proposal with new deployment plan
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-spec, sendme  |  Actual Points:
Parent ID:  #26288| Points:  0.1
 Reviewer:|Sponsor:  SponsorV
--+
Changes (by nickm):

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


Comment:

 LGTM; merged!

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

Re: [tor-bugs] #30451 [Circumvention/Snowflake]: snowflake-client has executable stack

[Tor Bug Tracker & Wiki]

#30451: snowflake-client has executable stack
-+
 Reporter:  boklm|  Owner:  cohosh
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201905 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  TorBrowserTeam201905R => TorBrowserTeam201905


Comment:

 Per chat with cohosh: I'd take the patch if there is an upcoming release
 anyway but I'd prefer if we can get the fix merged upstream as any
 additional patch we need in `tor-browser-build` is a bug we should try to
 fix. I heard there are folks in Cc to this ticket who are able to review
 and push the pull request. Let's try to go that route first with a new
 patch that just updates the `go-webrtc` commit once the patch landed.

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

Re: [tor-bugs] #30206 [Circumvention/Snowflake]: Segfault in proxy-go

[Tor Bug Tracker & Wiki]

#30206: Segfault in proxy-go
-+
 Reporter:  irl  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:12 arlolra]:
 >
 > One thing of note is that the goroutine was removed, which blocks
 `runSession()` from returning.  There's a similar question here as in
 ticket:30511#comment:4 on whether that deserves to called asynchronously.
 Yeah, we might want to add a timeout. I replied there:
 https://trac.torproject.org/projects/tor/ticket/30511#comment:5

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

Re: [tor-bugs] #30557 [Core Tor/Tor]: prop289: Update proposal with new deployment plan

[Tor Bug Tracker & Wiki]

#30557: prop289: Update proposal with new deployment plan
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, sendme  |  Actual Points:
Parent ID:  #26288| Points:  0.1
 Reviewer:|Sponsor:  SponsorV
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Spec branch: `ticket30557_01`

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

Re: [tor-bugs] #30511 [Circumvention/Snowflake]: Remove OnIceComplete

[Tor Bug Tracker & Wiki]

#30511: Remove OnIceComplete
-+--
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Also noting that with the current implementation, `pc.CreateAnswer` won't
 block indefinitely. It will time out and return `nil` after 3 seconds:
 [https://github.com/keroserene/go-
 webrtc/blob/a1272c08ab1d5ca154c6794ddc5f73d2e576fe1b/peerconnection.cc#L355
 peerconnection.cc#L355].

 It might be better practice to include our own timeout and not rely on the
 underlying implementation, at the very least we should document that this
 method times out since right now the documentation only mentions that it
 is blocking: https://godoc.org/github.com/keroserene/go-
 webrtc#PeerConnection.CreateAnswer

 I left the [https://github.com/cohosh/snowflake/blob/master/proxy-
 go/snowflake.go#L317 comment] to note that we might want to change this
 later.

 Otherwise the patches look good to me.

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

Re: [tor-bugs] #30555 [Applications/Tor Browser]: Android - Chrome not showing after bootstrap

[Tor Bug Tracker & Wiki]

#30555: Android - Chrome not showing after bootstrap
--+---
 Reporter:  sysrqb|  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 sysrqb):

 * status:  new => needs_information


Comment:

 I'm not having luck reproducing this. Hopefully this was a glitch on my
 device and no one else will experience it.

 For my attempt at reproducing, I installed 8.5a12 in an emulator running
 Android level 28 (Android 9). I launched the app, bootstrapped, and
 browsed to a website. Then I upgraded to 9.0a1 and opened the app again,
 and bootstrapped. After bootstrapping completed, the onboarding screen is
 shown followed by `about:tor`. After restarting the app again, it
 successfully bootstraps and `about:tor` is shown with the chrome.

 I don't think I did anything weird that would cause this bug...

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

Re: [tor-bugs] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#30237: Tor Browser: Improve TBB UI of hidden service client authorization
--+---
 Reporter:  asn   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:  #3| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+---
Changes (by antonela):

 * Attachment "http-auth.png" added.


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

Re: [tor-bugs] #30206 [Circumvention/Snowflake]: Segfault in proxy-go

[Tor Bug Tracker & Wiki]

#30206: Segfault in proxy-go
-+
 Reporter:  irl  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 Replying to [comment:11 cohosh]:
 > This patch looks good to me. I'm fine if you want to go ahead and merge
 it.

 Merged as https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=2e4383434f33a4f8e801974bbe70d8a4568b3d93

 One thing of note is that the goroutine was removed, which blocks
 `runSession()` from returning.  There's a similar question here as in
 ticket:30511#comment:4 on whether that deserves to called asynchronously.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30557 [Core Tor/Tor]: prop289: Update proposal with new deployment plan

[Tor Bug Tracker & Wiki]

#30557: prop289: Update proposal with new deployment plan
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec, sendme
Actual Points:|  Parent ID:  #26288
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorV  |
--+
 New plan is in 3 phases:

 1) emit=v1, accept=v0, protover=v0
 2) emit=v1, accept=v0, protover=v1
 3) emit=v1, accept=v1, protover=v1

 See https://trac.torproject.org/projects/tor/ticket/30364#comment:8 for
 the rationale.

 This ticket is only for updating proposal 289 text.

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

Re: [tor-bugs] #30364 [Core Tor/Tor]: prop289: Add consensus param to use or not SENDME v1 for one-hop directory download

[Tor Bug Tracker & Wiki]

#30364: prop289: Add consensus param to use or not SENDME v1 for one-hop 
directory
download
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  prop289, sendme, 0411-alpha, |  Actual Points:  0.2
  postfreeze-ok, 041-must|
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 After discussion with nickm on IRC, we'll drop this idea and instead go
 with this deployment plan:

 1) emit=v1, accept=v0, protover=v0
 2) emit=v1, accept=v0, protover=v1
 3) emit=v1, accept=v1, protover=v1

 Bottom line is that during phase 2, we will exit() all `tor` that do not
 support SENDME >= v1 but still accept v0 so bootstrapping tor can learn
 what is required. Finally, phase 3 will stop all this madness and
 normalize everyone to v1.

 This mean that we'll drop this ticket entirely. I've opened #30557 for the
 change on the spec.

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

Re: [tor-bugs] #30554 [Metrics/Onionperf]: Docs talk about scypy not scipy

[Tor Bug Tracker & Wiki]

#30554: Docs talk about scypy not scipy
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * 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] #30206 [Circumvention/Snowflake]: Segfault in proxy-go

[Tor Bug Tracker & Wiki]

#30206: Segfault in proxy-go
-+
 Reporter:  irl  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Good catch! Thanks for that.

 This patch looks good to me. I'm fine if you want to go ahead and merge
 it.

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

Re: [tor-bugs] #30537 [Applications/Tor Browser]: WebGL fingerprint is different between Windows versions (and compared to non-Windows OSes)

[Tor Bug Tracker & Wiki]

#30537: WebGL fingerprint is different between Windows versions (and compared to
non-Windows OSes)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, tbb- |  Actual Points:
  fingerprinting-os  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 So, that's due to Firefox doesn't recognize Win 10 renderer:
 {{{
 D3D11_COMPOSITING Blocklisted; failure code
 BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR
 }}}
 that changes the fingerprint and triggers:
 {{{
 Error: WebGL warning: Disallowing antialiased backbuffers due to
 blacklisting.  canvas.js:180:11
 }}}
 Forcing MSAA fixes that error, but doesn't change the fingerprint.

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

Re: [tor-bugs] #29697 [Internal Services]: archive.tpo is soon running out of space

[Tor Bug Tracker & Wiki]

#29697: archive.tpo is soon running out of space
---+
 Reporter:  boklm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by irl):

 I believe we have similar issues with CollecTor, although we're not going
 to hit problems very soon we are seriously lacking any redundancy other
 than the TPA backups. TPA backups are not guaranteed to be consistent
 because they are not CollecTor-aware so I've been thinking about building
 in some replication mechanisms using S3, probably looking at Glacier and
 IA as the targets. (S3 has the nice property that operations are atomic.)

 As far as I know the Software Heritage stack is built on Azure, so that
 would be independent of IA/AWS if they were interested in also hosting a
 copy of Tor Metrics' archive.

 I would be happy to talk about options in a session in Stockholm if time
 permits, although it is starting to look as if it is going to be very busy
 there. We could also have a call to look at options, or we could treat
 these as different problems and have different solutions to them.

 I would be extremely sad if the plan is to delete anything.

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

Re: [tor-bugs] #30549 [Applications/Tor Browser]: Add script to remove expired sub-keys from a keyring file

[Tor Bug Tracker & Wiki]

#30549: Add script to remove expired sub-keys from a keyring file
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201905R, tbb-rbm  |  Actual Points:
Parent ID:  #30548  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:2 gk]:
 > The commit message says things like "Add script to remove expired sub-
 keys from a keyring file" but then we have
 > {{{
 > +# Drop expired and revoked sub-keys from a keyring file
 > }}}
 > Looking at the code it seems we indeed want to take care of both expired
 and explicitly revoked keys. That's right?

 Yes. I updated the commit message in in branch `bug_30549_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_30549_v2=0b258f07310f8180810558930f79f13d2d4d7906

 >
 > If we apply that script how can we prevent removing expired subkeys we
 actually *still need* for building by accident?

 We should only use this script when we want to remove all expired sub-
 keys. I added a comment in the script mentioning that.

 For the cases where we need to keep some of the expired-keys, but not all,
 I am not sure yet what is the best way to do that, as gpg does not seem to
 make it easy to keep only some of the expired sub-keys. Maybe using the
 script with faketime would work, but I didn't try.

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

Re: [tor-bugs] #30555 [Applications/Tor Browser]: Android - Chrome not showing after bootstrap

[Tor Bug Tracker & Wiki]

#30555: Android - Chrome not showing after bootstrap
--+--
 Reporter:  sysrqb|  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:
--+--

Comment (by sysrqb):

 (this is was 9.0a1 on Android API 28)

 Restarting the app and going through bootstrap again "fixed" the problem.
 I'll try to reproduce this.

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

Re: [tor-bugs] #30556 [Applications/Tor Browser]: Re-evaluate letterboxing dimension choices

[Tor Bug Tracker & Wiki]

#30556: Re-evaluate letterboxing dimension choices
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * Attachment "Content Resolution Analysis(10).ipynb" added.


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

[tor-bugs] #30556 [Applications/Tor Browser]: Re-evaluate letterboxing dimension choices

[Tor Bug Tracker & Wiki]

#30556: Re-evaluate letterboxing dimension choices
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 At some point, maybe we should reconsider our choice for letterboxing
 dimensions.

 This ticket is primarily to serve as a place to attach my ipython script
 for safekeeping for years from now.

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

[tor-bugs] #30555 [Applications/Tor Browser]: Android - Chrome not showing after bootstrap

[Tor Bug Tracker & Wiki]

#30555: Android - Chrome not showing after bootstrap
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 After bootstrapping completes, `about:tor` is shown but the chrome remains
 `GONE`.

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

Re: [tor-bugs] #29697 [Internal Services]: archive.tpo is soon running out of space

[Tor Bug Tracker & Wiki]

#29697: archive.tpo is soon running out of space
---+
 Reporter:  boklm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by anarcat):

 TL;DR: possible paths:

  1. Internet Archive (IA)
  2. Software Heritage
  3. commercial storage (e.g. Amazon Glacier)
  4. host our own
  5. spend more time deciding on archival policies
  6. mix of the above

 One way to manage stuff like this is to break it up in smaller pieces and
 distribute it around. a typical way I manage those archives is with git-
 annex, which allows for reliable tracking of N copies (say "3 redundant
 copies") and supports *many* different "remotes", including Amazon
 Glacier, Internet Archive (IA) and so on. It's what I used in the Brazil
 archival project and it mostly worked. It's hard to use, unfortunately,
 which may be a big blocker for adoption.

 If git-annex is too complicated, we can talk to IA directly. I would
 recommend, however, against using their web-based upload interface which,
 even they acknowledge, is terrible and barely useable. I packaged the
 [https://tracker.debian.org/pkg/python-internetarchive internetarchive]
 python client in Debian to work around that problem and it works much
 better.

 Moving files to IA only shifts the problem, in my opinion: then we have
 only a single copy, elsewhere and while we don't need to manage that space
 anymore, we also don't manage backups and will never know if they drop
 stuff on us (and they do, sometimes, either deliberately or by mistake). I
 would propose that if stuff moves out of our "backed-up" infrastructure,
 it should be stored in at least two administratively distinct locations.

 Another such location we could use, apart from commercial providers like
 Amazon, is the [http://softwareheritage.org/ Software Heritage] project
 ([https://en.wikipedia.org/wiki/Software_Heritage WP]) which is *designed*
 to store copies of source code and software artifacts of all breeds. It
 might already have something for Tor even.

 Otherwise, assuming we can solve this problem ourselves, I think this
 question boils down to "How big of an archive do we actually need and how
 fast does it grow?" With the limited Grafana history I had  available a
 week ago, I have calculated we dump roughly ~10GB per week of new stuff on
 there, but naturally the sample size is too small to take that number
 seriously. To give you another metric, in the last two weeks now (one week
 later), we have gone from 254GB to 207GB, eating a whopping 47GB in 15
 days, which clocks the rate at ~3GB a day or ~24GB a week. When I looked
 at it a week ago, we had 220GB left, which gives us a rate of 13GB/week,
 so I would estimate the burn rate is between 10 to 20GB/week, which gives
 us about 10 to 20 weeks to act on this problem.

 Assuming 10GB/week, this means we need ~500GB of *new* storage every year.
 In our current capacity, this trickles into roughly 2x1TB of storage per
 year because of RAID and backups.

 So if we want this problem to go away for ~10 years (assuming current
 rate, which is probably inaccurate, at beast), we could throw hardware at
 the problem and give Hetzner another ~200EUR/mth specifically for an
 archival server. We might be able to save some costs by *not* backing up
 the server and using IA/Software Heritage as a fallback, with git-annex as
 well.

 Fundamentally, this is a cost problem. Do you want us to spend time to
 figure out a proper archival policy and cheap/free storage locations or
 pay for an archival server?

 In any case, I'd be happy to dig deeper into this to figure out the
 various options beyond the above napkin calculations.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30554 [Metrics/Onionperf]: Docs talk about scypy not scipy

[Tor Bug Tracker & Wiki]

#30554: Docs talk about scypy not scipy
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 For deployment instructions

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

Re: [tor-bugs] #30364 [Core Tor/Tor]: prop289: Add consensus param to use or not SENDME v1 for one-hop directory download

[Tor Bug Tracker & Wiki]

#30364: prop289: Add consensus param to use or not SENDME v1 for one-hop 
directory
download
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, sendme, 0411-alpha, |  Actual Points:  0.2
  postfreeze-ok, 041-must|
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_information => 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

Re: [tor-bugs] #30364 [Core Tor/Tor]: prop289: Add consensus param to use or not SENDME v1 for one-hop directory download

[Tor Bug Tracker & Wiki]

#30364: prop289: Add consensus param to use or not SENDME v1 for one-hop 
directory
download
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, sendme, 0411-alpha, |  Actual Points:  0.2
  postfreeze-ok, 041-must|
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_information


Comment:

 Interesting... I have one question there that will drive quite a bit how
 everything else is fixed. Once that is clarified, I might just submit an
 `_02` since like more than 50% of the patch will change... Thanks!

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

Re: [tor-bugs] #30428 [Core Tor/Tor]: sendme: Failure to validate authenticated SENDMEs client side

[Tor Bug Tracker & Wiki]

#30428: sendme: Failure to validate authenticated SENDMEs client side
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, sendme, 041-must,   |  Actual Points:
  0411-alpha, postfreeze-ok  |
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Comments addressed.

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

Re: [tor-bugs] #30546 [Internal Services/Service - git]: Create a metrics-cloud and user/irl/metrics-cloud repository

[Tor Bug Tracker & Wiki]

#30546: Create a metrics-cloud and user/irl/metrics-cloud repository
-+
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

 * status:  assigned => 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] #29757 [Applications/Tor Browser]: TBA: Delete Orbot Providers

[Tor Bug Tracker & Wiki]

#29757: TBA: Delete Orbot Providers
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:1 sysrqb]:
 > Note to self: the Tor port numbers conflict, as well. Future ticket.

 That's now #30551

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30553 [Core Tor/Chutney]: chutney: Bump the data size transmitted with the verify command

[Tor Bug Tracker & Wiki]

#30553: chutney: Bump the data size transmitted with the verify command
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 With #29263, the SENDMEs can be tested properly but as long as the
 circuits has more than 500KB on it (which is roughly the 512 byte data
 cell size times the circuit window start of 1000).

 To be safe, having let say 600KB of data transmitted with `chutney verify`
 would be a sure test of the circuit flow control feature. And it doesn't
 take much more time at all from what we have right now.

 On slow systems like arm64 for instance, there could be an argument to
 bump the SOCKS timeout from 3 to let say 5 or 10 seconds in order to avoid
 chutney killing the connections before 600KB went through 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

[tor-bugs] #30552 [Applications/Tor Browser]: Android - Clean up torrc

[Tor Bug Tracker & Wiki]

#30552: Android - Clean up torrc
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As mentioned in ticket:30284#comment:22 and shown in
 ticket:30518#comment:3, the current torrc file has many entries we don't
 need. Let's clean out that file and only include the pieces 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

[tor-bugs] #30551 [Applications/Tor Browser]: Android - Use different port numbers

[Tor Bug Tracker & Wiki]

#30551: Android - Use different port numbers
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #29757 we looked at one issue preventing side-by-side installation of
 Tor Browser on Android. The next issue is running multiple versions at the
 same time. Tor is started with some hard-coded port numbers (see
 [ticket:30518#comment:3 for example]) in Tor Browser stable and alpha, and
 this prevents bootstrapping on the second instance (because tor can't bind
 on those sockets). We should allow running stable and alpha at the same
 time by choosing different port numbers for them.

 Specifically, we should look at TransPort (9140) and HTTPTunnelPort
 (8218). Currently, we don't need either of these. (We also don't need the
 DNSPort on 5400).

 I also wonder why/how the app works if the SocksPort is selected randomly.

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

Re: [tor-bugs] #30549 [Applications/Tor Browser]: Add script to remove expired sub-keys from a keyring file

[Tor Bug Tracker & Wiki]

#30549: Add script to remove expired sub-keys from a keyring file
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201905R, tbb-rbm  |  Actual Points:
Parent ID:  #30548  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 The commit message says things like "Add script to remove expired sub-keys
 from a keyring file" but then we have
 {{{
 +# Drop expired and revoked sub-keys from a keyring file
 }}}
 Looking at the code it seems we indeed want to take care of both expired
 and explicitly revoked keys. That's right?

 If we apply that script how can we prevent removing expired subkeys we
 actually *still need* for building by accident?

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

Re: [tor-bugs] #30533 [Core Tor/DirAuth]: Bandwidth Unmeasured in Testing Tor Network

[Tor Bug Tracker & Wiki]

#30533: Bandwidth Unmeasured in Testing Tor Network
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DirAuth |Version:  Tor:
 |  0.3.3.8
 Severity:  Normal   | Resolution:
 Keywords:  Bandwiidth, Testing Tor Network  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 First off, 0.3.3.8 isn't supported. If it turns out that the problem is
 related to the version, we van't help much.

 Second, a question: are you running any bandwidth authorities on this
 network?  If not, bandwidth won't get measured.

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

Re: [tor-bugs] #30480 [Applications/rbm]: rbm should check that a signed tag object contains the expected tag name

[Tor Bug Tracker & Wiki]

#30480: rbm should check that a signed tag object contains the expected tag name
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  TorBrowserTeam201905R => TorBrowserTeam201905


Comment:

 I guess
 {{{
 +return $1 if $l =~ m/^tag (.*)$/;
 }}}
 is assuming that the first such line showing up is the one we want and an
 attacker can't get to enter fake tag lines (like they can do with a commit
 message) before that? If so, could we add a comment here?

 s/helping fix/helping to fix/

 Otherwise this looks good to me.

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

Re: [tor-bugs] #30187 [Core Tor/Tor]: 100% cpu usage in winthreads tor_cond_wait

[Tor Bug Tracker & Wiki]

#30187: 100% cpu usage in winthreads tor_cond_wait
---+---
 Reporter:  bolvan |  Owner:  ahf
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.8
 Severity:  Normal | Resolution:
 Keywords:  windows 035-backport 042-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by bolvan):

 It doesnt seem to be related to the compiler. Its a bug in the windows
 specific code.
 I compiled in recent wingw-w64 on windows and bug was 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

Re: [tor-bugs] #30187 [Core Tor/Tor]: 100% cpu usage in winthreads tor_cond_wait

[Tor Bug Tracker & Wiki]

#30187: 100% cpu usage in winthreads tor_cond_wait
---+---
 Reporter:  bolvan |  Owner:  ahf
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.8
 Severity:  Normal | Resolution:
 Keywords:  windows 035-backport 042-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Is this reproducible with MinGW-W64 trunk?

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

Re: [tor-bugs] #15999 [Core Tor/Stem]: End-to-end integ test for hidden service

[Tor Bug Tracker & Wiki]

#15999: End-to-end integ test for hidden service
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  testing|  Actual Points:
Parent ID: | Points:
---+

Comment (by 0xrichard):

 Tests for this are included in

 https://github.com/rj76/stem/pull/2/files

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

Re: [tor-bugs] #30545 [Core Tor/Tor]: must not *skip* obsolete options.

[Tor Bug Tracker & Wiki]

#30545: must not *skip* obsolete options.
--+--
 Reporter:  weasel|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Per discussion on IRC: I think we need to have two categories of obsolete
 options: one of which is ignored and causes a warning, and the other of
 which causes a failure to start. We should partition our list of obsolete
 options into these categories, based on our best guess of user preference.

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

Re: [tor-bugs] #30187 [Core Tor/Tor]: 100% cpu usage in winthreads tor_cond_wait

[Tor Bug Tracker & Wiki]

#30187: 100% cpu usage in winthreads tor_cond_wait
---+---
 Reporter:  bolvan |  Owner:  ahf
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.8
 Severity:  Normal | Resolution:
 Keywords:  windows 035-backport 042-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by ahf):

 It is serious and we plan on fixing this bug. Right now (end of May 2019)
 we are finishing off a sponsor and trying to get 0.4.1 shipped. Once we
 are done with that work, we will get to this. The priority of this bug is
 still considered 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] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed,  |  Actual Points:  0.2
  029-backport, 034-backport, 035-backport,  |
  040-backport, 041-should   |
Parent ID:   | Points:  2
 Reviewer:  nickm|Sponsor:
-+-

Comment (by cypherpunks):

 > So the UBSan runtime reports divisions by zero, but the UBSan trap does
 not? That's also really weird.
 Clang has very poor documentation, but a lot of features come from GCC,
 and Clang's devs recommend to use GCC docs :( plus "read the source" :(
 So, here's where it comes from (GCC):
 "Unlike other similar options, -fsanitize=float-divide-by-zero is not
 enabled by -fsanitize=undefined, since floating-point division by zero can
 be a legitimate way of obtaining infinities and NaNs."
 And `trap` one has the same default behavior:
 "The -fsanitize-undefined-trap-on-error option instructs the compiler to
 report undefined behavior using `__builtin_trap` rather than a libubsan
 library routine. The advantage of this is that the libubsan library is not
 needed and is not linked in, so this is usable even in freestanding
 environments."
 > And makes it hard to work out which one we should use.
 Should? You should try to ship Tor with production-grade version of UBSan:
 https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#minimal-
 runtime

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

Re: [tor-bugs] #30187 [Core Tor/Tor]: 100% cpu usage in winthreads tor_cond_wait

[Tor Bug Tracker & Wiki]

#30187: 100% cpu usage in winthreads tor_cond_wait
---+---
 Reporter:  bolvan |  Owner:  ahf
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.5.8
 Severity:  Normal | Resolution:
 Keywords:  windows 035-backport 042-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by bolvan):

 This bugs makes tor relay unusable under windows.
 All windows relay operators should stop their nodes.
 Is it serious enough ?

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

Re: [tor-bugs] #28793 [Core Tor/Fallback Scripts]: Rebuild the fallback list in 2019

[Tor Bug Tracker & Wiki]

#28793: Rebuild the fallback list in 2019
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback, 041-should   |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  fallback => fallback, 041-should


Comment:

 Our fallback checks are failing, because 25% of fallbacks are down.

 So we should do this ticket in 0.4.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

Re: [tor-bugs] #29617 [Core Tor/Tor]: OOM manger wipes entire DNS cache

[Tor Bug Tracker & Wiki]

#29617: OOM manger wipes entire DNS cache
-+-
 Reporter:  pulls|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  035-backport, 040-backport, fast-|  Actual Points:  0
  fix, easy, 041-should, dgoulet-merge   |
Parent ID:   | Points:  0
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:  035-backport, 040-backport, fast-fix, easy, 041-should =>
 035-backport, 040-backport, fast-fix, easy, 041-should, dgoulet-merge


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

Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2, 0411-alpha, 041-should  |
Parent ID:   | Points:  8
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * status:  assigned => merge_ready


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

Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2, 0411-alpha, 041-should  |
Parent ID:   | Points:  8
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * owner:  (none) => mikeperry
 * status:  merge_ready => 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] #30454 [Core Tor/Tor]: hs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAY

[Tor Bug Tracker & Wiki]

#30454: hs-v3: INTRODUCE1 trunnel code doensn't handle
HS_INTRO_ACK_STATUS_CANT_RELAY
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-backport, 035-backport,  |  Actual Points:
  040-backport, 041-must, nickm-merge, network-  |
  team-roadmap-2019-Q1Q2, 0411-alpha |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by teor):

 * status:  assigned => merge_ready


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

Re: [tor-bugs] #30454 [Core Tor/Tor]: hs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAY

[Tor Bug Tracker & Wiki]

#30454: hs-v3: INTRODUCE1 trunnel code doensn't handle
HS_INTRO_ACK_STATUS_CANT_RELAY
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-backport, 035-backport,  |  Actual Points:
  040-backport, 041-must, nickm-merge, network-  |
  team-roadmap-2019-Q1Q2, 0411-alpha |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by teor):

 * status:  merge_ready => assigned
 * owner:  (none) => dgoulet


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

Re: [tor-bugs] #28694 [Core Tor/sbws]: When CircuitPadding is implemented in Tor, set it to 0 in sbws

[Tor Bug Tracker & Wiki]

#28694: When CircuitPadding is implemented in Tor, set it to 0 in sbws
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, changes-version-patch, sbws-11x-  |
  final-removed-20190312, scanner, 041-should|
Parent ID:  #29954   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:
 wtf-pad, tor-relay, tor-cell, padding, changes-version-patch, sbws-
 11x-final-removed-20190312, scanner, 041-must
 =>
 wtf-pad, tor-relay, tor-cell, padding, changes-version-patch, sbws-
 11x-final-removed-20190312, scanner, 041-should


Comment:

 We won't block on this ticket, because padding doesn't affect sbws
 circuits yet.
 But we should keep the sbws options up to date with tor, because that's an
 sbws best practice.

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

Re: [tor-bugs] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Another operator moved their relay from 5.196.88.122 -> 192.99.201.189:
 https://twitter.com/florent_ato/status/1130329580504518656?s=21

 I think the fallback list script automatically accepts IP address changes
 as long as the fingerprint is the same.
 But we should keep the details up to date anyway.

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

Re: [tor-bugs] #30479 [Applications/Tor Browser]: Move away from using signed git tags to avoid rollback attacks?

[Tor Bug Tracker & Wiki]

#30479: Move away from using signed git tags to avoid rollback attacks?
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Related to the issue of signatures made with expired keys, I opened #30548
 to clean up our keyring files to remove any key that we don't need, and
 #30549 to make that easier to do.

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

Re: [tor-bugs] #30550 [Core Tor/Tor]: Remove torctl.in from contrib/dist

[Tor Bug Tracker & Wiki]

#30550: Remove torctl.in from contrib/dist
--+--
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


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