Re: [tor-bugs] #32352 [Core Tor/Tor]: Stop adding a space when dumping an empty config value

[Tor Bug Tracker & Wiki]

#32352: Stop adding a space when dumping an empty config value
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  BugSmashFund, no-backport  |  Actual Points:  0.1
Parent ID:  #32213 | Points:  0.1
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  assigned => needs_revision


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

[tor-bugs] #32352 [Core Tor/Tor]: Stop adding a space when dumping an empty config value

[Tor Bug Tracker & Wiki]

#32352: Stop adding a space when dumping an empty config value
--+---
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  BugSmashFund, no-backport
Actual Points:  0.1   |  Parent ID:  #32213
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+---
 We unconditionally add a space when dumping torrc files, even if there is
 no option value. (Which is rare, but does happen with some list options.)

 The extra space is unnecessary and we should remove it.

 This bug has been around since Tor 0.0.9pre6.

 The fix is in this commit, I need to extract it and add a changes file:
 
https://github.com/torproject/tor/pull/1477/commits/67d0178f1aba0a424364acc1c9f9dff2c72886a4

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

Re: [tor-bugs] #32213 [Core Tor/Tor]: Phase 1: Disable minimal dirauth and relay options when those modules are disabled

[Tor Bug Tracker & Wiki]

#32213: Phase 1: Disable minimal dirauth and relay options when those modules 
are
disabled
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  4.5
  october|
Parent ID:  #31851   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-must
-+-

Comment (by teor):

 Improving the test coverage for option validation is easy with
 test_parseconf.sh, but it's time-consuming. Improving the test coverage
 for options_act() could take a bit more work.

 I pushed some more tests, and a fix for a bug I found in the new config
 code. I'll make a child ticket.

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

Re: [tor-bugs] #30501 [Applications/Tor Browser]: BridgesList Preferences is an overloaded field

[Tor Bug Tracker & Wiki]

#30501: BridgesList Preferences is an overloaded field
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911R  |  Actual Points:
Parent ID:  #31280 | Points:  2
 Reviewer: |Sponsor:
   |  Sponsor30-can
---+---
Changes (by sisbell):

 * status:  needs_revision => needs_review
 * keywords:  tbb-mobile, TorBrowserTeam201910 => tbb-mobile,
 TorBrowserTeam201911R


Comment:

 I collapsed #30552 into the same commit since it involves same code area.
 I removed the shuffling, removed max bridge check, renamed methods to make
 clearer, more tests, more docs. For one case, I check for existence of
 bridges.txt before setting bridges flag. Various other changes, cleanups.

 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/b72487be7b53d1ffcbd5f3942f2d0f7b1c79c859

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

Re: [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:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201910  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by sisbell):

 Replying to [comment:8 sysrqb]:
 > Replying to [comment:6 sisbell]:
 > > I made the following changes to tor-onion-proxy-library. If the
 changes look good, I will need to make it compatible with tor-android-
 service.
 >
 > I think it would make more sense leaving TOPL's defaults unchanged, as
 much as possible. I don't see a problem with explicitly setting default
 values in the torrc (like `TestSocks 0`), but I do like cleaner defaults
 and a cleaner/smaller generated torrc.
 >
 >
 > >
 > > * StrictNodes, UseBridges, SafeSocks, TestSocks will not be included
 in the torrc if they have a 0 value
 >
 > I don't have a strong opinion on this. It doesn't really have any impact
 until tor's default values change for whatever reason.
 >
 >
 > > * DnsPort, HttpTunnelPort, TransparentProxyPort are now all Integers.
 I also added an associated host field for each one.
 > > * ProxyPort, ProxySocks5ServerPort are now an Integers rather than
 Strings.
 > > * HttpTunnelPort and TransPort values are set to null so it won't
 appear in torrc by default.
 > > * AutomapHostsOnResolve is set to false so won't appear in torrc by
 default
 >
 > These are the more important changes.
 >
 >
 > >
 > > The remaining field VirtualAddrNetwork will need to be removed in tor-
 android-service
 > >
 > >
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/73aeed144259a66930e605c7804946c9f6041b59
 > >
 >
 >
 
`universal/src/main/java/com/msopentech/thali/toronionproxy/DefaultSettings.java`
 > {{{
 >  @Override
 > -public int getHttpTunnelPort() {
 > -return 8118;
 > +public String getHttpTunnelHost() {
 > +return null;
 > +}
 > +
 > +@Override
 > +public Integer getHttpTunnelPort() {
 > +return null;
 >  }
 > }}}
 > This is changing the default port, is that intentional?

 Yes, I don't believe we use this by default. it can be set in tor-android-
 service if needed.
 >
 > {{{
 >  @Override
 > -public String transPort() {
 > -return "9040";
 > +public String getTransparentProxyAddress() {
 > +return null;
 > +}
 > +
 > +@Override
 > +public Integer getTransparentProxyPort() {
 > +return null;
 > }}}
 > This is changing the default port, is that intentional?
 Yes, I don't believe we use this by default. it can be set in tor-android-
 service if needed.
 >
 > {{{
 > +TorConfigBuilder addAddress(String fieldName, String address,
 Integer port, String flags) {
 > +if(isNullOrEmpty(address) && port == null) {
 > +return this;
 > +}
 > +buffer.append(fieldName).append(" ");
 > +if(!isNullOrEmpty(address)) {
 > +buffer.append(address).append(":");
 > +}
 > +if (port != null) {
 > +buffer.append(port <= 0 ? "auto" : port);
 > }}}
 > Please pass this directly to tor, we shouldn't change the intended
 behavior if the app configures a 0 or negative port number. Tor will emit
 a warning which the app should handle itself.
 The negative int or null value is treated a "magic" number for "auto".
 This is really because tor config accepts strings (auto) or int types for
 port so we have to be able to handle this somehow.

 >
 >
 
`universal/src/test/java/com/msopentech/thali/toronionproxy/TorConfigBuilderTest.java`
 >
 > {{{
 > +/**
 > + * SHould be empty
 > + */
 > }}}
 > nit.

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

Re: [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:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201910  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by sisbell):

 Replying to [comment:10 sysrqb]:
 > Something else, but not for this ticket, is that TOPL should be
 consistent about how it handles integer config options.
 >
 > {{{
 > @Override
 > public String getSocksPort() {
 > return "9050";
 > }
 > }}}
 >

 I left this since we also need to handle "auto" and we have the auto
 detect on the port so its a bigger change for this field.
 > At this point, I don't think it matters if they are stored and handled
 as Strings or Integers, but they should all be the same.

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

Re: [tor-bugs] #30783 [Applications/Tor Browser]: End of Year Fundraising Campaign - about:tor

[Tor Bug Tracker & Wiki]

#30783: End of Year Fundraising Campaign - about:tor
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0,|  Actual Points:  1.5
  TorBrowserTeam201910R  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 acat, can you review this and test it?

 https://github.com/sysrqb/torbutton
 branch `bug30783_mobile_00`

 I haven't tested it on desktop yet (still building).

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

Re: [tor-bugs] #30783 [Applications/Tor Browser]: End of Year Fundraising Campaign - about:tor

[Tor Bug Tracker & Wiki]

#30783: End of Year Fundraising Campaign - about:tor
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0,|  Actual Points:  1.5
  TorBrowserTeam201910R  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:27 gk]:
 > Maybe the metrics folks could check the useragent string before it gets
 sanitized? That would save us some work and last minute changes.
 irl confirmed we don't have access to the UAS before sanitization, so I
 modified the patch so it uses `/donate/donate-tbi-mobile-*`.

 During testing, I noticed the pre-existing "Keep Tor Strong. Donate Now"
 link is still using the old url (directly for donate.tpo) and it seems
 like people may click that link instead of the large purple-and-black
 button. I patched this so both links use the same url.

 I can see us using slightly different urls for the two links, but we can
 think about that for the next iteration.

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

Re: [tor-bugs] #32339 [Core Tor/Tor]: Use a table to drive options_check_transition and warn_about_relative_paths

[Tor Bug Tracker & Wiki]

#32339: Use a table to drive options_check_transition and 
warn_about_relative_paths
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-?  |  Actual Points:  .1
Parent ID:  #29211  | Points:  1
 Reviewer:  teor|Sponsor:  Sponsor31-can
+

Comment (by teor):

 We should be able to loop through Logs like we do HiddenServiceDir?
 Maybe we'll need to do that after we've parsed Logs into log objects.
 I'll see if I can write some code for 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] #32344 [Core Tor/Tor]: Make immutability into a config_var_t flag

[Tor Bug Tracker & Wiki]

#32344: Make immutability into a config_var_t flag
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  .2
Parent ID:  #29211 | Points:
 Reviewer:  teor   |Sponsor:
---+---

Comment (by teor):

 How many kinds of immutability do we need?

 Flags work well if we have a small number of simple kinds of immutability.
 But they still centralise some code.

 We could let modules define an immutability function that gets run on
 every option?
 For example, a sandbox_config module would define an immutability function
 that prevents filenames, IP addresses, and other options changing.
 And if we have relay or dirauth immutability, then those modules could
 define those functions.

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

Re: [tor-bugs] #32239 [Internal Services/Tor Sysadmin Team]: setup a cache frontend for the blog

[Tor Bug Tracker & Wiki]

#32239: setup a cache frontend for the blog
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32090   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> design docs in https://help.torproject.org/tsa/howto/cache/
>
> launch checklist:
>
>  1. alternatives listing and comparison (done)
>  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
>  3. benchmark the different alternatives (done, ATS and nginx comparable)
>  4. setup secondary node with Puppet, say `cache-02.tpo` (done)
>  4. validation benchmark against both nodes (done)
>  5. lower DNS to 10 minutes wait an hour (done)
>  6. lower DNS to 3 minutes
>  7. *add* one node to the DNS, check if traffic flows properly after 10
> minutes
>  8. add the other node to DNS, again checking traffic
>  9. if all is well, remove backend from DNS
>  10. raise DNS back to 1h if all goes well.
>
> Disaster recovery:
>
>  1. flip DNS back to backend

New description:

 design docs in https://help.torproject.org/tsa/howto/cache/

 launch checklist:

  1. alternatives listing and comparison (done)
  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
  3. benchmark the different alternatives (done, ATS and nginx comparable)
  4. setup secondary node with Puppet, say `cache-02.tpo` (done)
  4. validation benchmark against both nodes (done)
  5. lower DNS to 10 minutes wait an hour (done)
  6. open firewall
  7. lower DNS to 3 minutes
  8. *add* one node to the DNS, check if traffic flows properly after 10
 minutes
  9. add the other node to DNS, again checking traffic
  10. if all is well, remove backend from DNS
  11. raise DNS back to 1h if all goes well.

 Disaster recovery:

  1. flip DNS back to backend

--

Comment (by anarcat):

 forgot that we need to open firewall

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

Re: [tor-bugs] #32239 [Internal Services/Tor Sysadmin Team]: setup a cache frontend for the blog

[Tor Bug Tracker & Wiki]

#32239: setup a cache frontend for the blog
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32090   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> design docs in https://help.torproject.org/tsa/howto/cache/
>
> launch checklist:
>
>  1. alternatives listing and comparison (done)
>  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
>  3. benchmark the different alternatives (done, ATS and nginx comparable)
>  4. setup secondary node with Puppet, say `cache-02.tpo` (done)
>  4. validation benchmark against both nodes (partial)
>  5. lower DNS to 300 seconds, wait an hour (set TTL to 10min, waiting)
>  6. flip DNS to the cache node, wait and monitor for 5 minutes
>  7. raise DNS back to 1h if all goes well.
>
> Disaster recovery:
>
>  1. flip DNS back to pantheon

New description:

 design docs in https://help.torproject.org/tsa/howto/cache/

 launch checklist:

  1. alternatives listing and comparison (done)
  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
  3. benchmark the different alternatives (done, ATS and nginx comparable)
  4. setup secondary node with Puppet, say `cache-02.tpo` (done)
  4. validation benchmark against both nodes (done)
  5. lower DNS to 10 minutes wait an hour (done)
  6. lower DNS to 3 minutes
  7. *add* one node to the DNS, check if traffic flows properly after 10
 minutes
  8. add the other node to DNS, again checking traffic
  9. if all is well, remove backend from DNS
  10. raise DNS back to 1h if all goes well.

 Disaster recovery:

  1. flip DNS back to backend

--

Comment (by anarcat):

 the original node is now setup with puppet as well. ran into a problem
 when trying to figure out hit ratios: those stats are available only in
 the commercial version.

 we might need to pipe stuff through mtail to get those metrics in
 prometheus. in the meantime, maybe we can still launch without those? :/

 the TTL is still low, and i am thinking of launching tomorrow if nothing
 else comes up. i've changed the procedure slightly to *add* the caching
 servers in the pool instead of replacing the backend completely. that way
 we have a smoother transition and can fall back more easily if something
 goes wrong.

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

Re: [tor-bugs] #31244 [Internal Services/Tor Sysadmin Team]: long term prometheus metrics

[Tor Bug Tracker & Wiki]

#31244: long term prometheus metrics
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 it has not been 30 days yet, but we are still seeing problem and worse,
 all rate graphs have been broken by this change. Because rates are usually
 over 5 minutes, Prometheus freaks out and Grafana spews out "no data" on
 critical graphs like network usage. I've pushed this back to 1m scrape
 interval but kept the 365d retention. This might eventually cause
 problems, but we have plenty of time to deal with those and I need those
 graphs back online ASAP.

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

Re: [tor-bugs] #32255 [Applications/Tor Browser]: Missing ORIGIN header breaks CORS in Tor Browser 9.0

[Tor Bug Tracker & Wiki]

#32255: Missing ORIGIN header breaks CORS in Tor Browser 9.0
-+-
 Reporter:  complexparadox   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:
  regression, TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 It seems this is now controlled by `network.http.referer.hideOnionSource`
 (changed in https://bugzilla.mozilla.org/show_bug.cgi?id=1503736). Was
 this pref supposed to affect all requests or just hiding the referer when
 navigating from an onion website to a non-onion one?

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 The last time we encountered the issue was #28144

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

Re: [tor-bugs] #27604 [Applications/Tor Browser]: Relocating the Tor Browser directory is broken with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27604: Relocating the Tor Browser directory is broken with Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:  3
  tbb-8.0.1-can, TorBrowserTeam201910R, tbb- |
  backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-8.0-issues, tbb-regression, tbb-8.0.1-can,
 TorBrowserTeam201910 =>
 tbb-8.0-issues, tbb-regression, tbb-8.0.1-can, TorBrowserTeam201910R,
 tbb-backport
 * status:  needs_revision => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:37 acat]:
 > I can't reproduce... Which exact files did you remove to get these?

 Hrm. It seems I can't reproduce that anymore with clean bundles, sorry for
 the noise. I wonder what I did do differently before, though... Anyway,
 nice work! I cherry-picked you patch onto `tor-browser-68.2.0esr-9.5-1`
 (commit 7d5f879bba1e81ee64576e882f9d8916a2bc471e).

 It will be interesting to see what Mozilla folks are saying. One thing we
 should not forget when upstreaming is including a test that makes sure
 this scenario is still working. It seems over time more and more
 functionality crept in that broke the relocation scenario.

 We mght want to backport the changes at some point but not sure. This
 will probably be sysrqb's decision.

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:7 sysrqb]:
 > I worry there are other bugs lurking as a result of our unzip/zip, but I
 don't have a better solution right now.
 In fact:
 {{{
 $ unzip -vl tor-browser-9.0a7-android-x86_64-multi.apk | grep -c Stored
 981
 $ unzip -vl tor-browser-9.0a8-android-x86_64-multi.apk | grep -c Stored
 45
 }}}

 {{{
 $ unzip -vl tor-browser-9.0a7-android-x86_64-multi.apk | grep -c Defl:N
 17
 $ unzip -vl tor-browser-9.0a8-android-x86_64-multi.apk | grep -c Defl:N
 1516
 }}}

 These numbers aren't very helpful, except showing the majority of files in
 `9.0a7` are `Stored` while the majority of files in `9.0a8` are `Defl:N`.

 A little more informative:
 {{{

 $ unzip -vl tor-browser-9.0a7-android-x86_64-multi.apk | grep Defl:N
  1858081  Defl:N  1787604   4% 2000-01-01 00:00 6e9c0248
 assets/distribution/extensions/https-everywhere-...@eff.org.xpi
   548510  Defl:N   537879   2% 2000-01-01 00:00 f556e20f
 assets/distribution/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
  7105248  Defl:N  2391049  66% 2000-01-01 00:00 2bb41c2d
 lib/x86_64/libObfs4proxy.so
  7478968  Defl:N  2698159  64% 2000-01-01 00:00 f391dcb9
 lib/x86_64/libTor.so
   510160  Defl:N   210494  59% 2000-01-01 00:00 d10747be
 lib/x86_64/libfreebl3.so
30728  Defl:N12928  58% 2000-01-01 00:00 07c892e9
 lib/x86_64/liblgpllibs.so
  1781088  Defl:N   593355  67% 2000-01-01 00:00 dcacddb5
 lib/x86_64/libmozavcodec.so
   186608  Defl:N71807  62% 2000-01-01 00:00 fe062a40
 lib/x86_64/libmozavutil.so
  1174440  Defl:N   417613  64% 2000-01-01 00:00 3169aef4
 lib/x86_64/libmozglue.so
  1884528  Defl:N   912276  52% 2000-01-01 00:00 025746a3
 lib/x86_64/libnss3.so
   450840  Defl:N   181388  60% 2000-01-01 00:00 ed1e782b
 lib/x86_64/libnssckbi.so
 6144  Defl:N 1701  72% 2000-01-01 00:00 4fb02e64  lib/x86_64
 /libplugin-container.so
   248776  Defl:N   103114  59% 2000-01-01 00:00 36153725
 lib/x86_64/libsoftokn3.so
 86656560  Defl:N 32635129  62% 2000-01-01 00:00 355d0169
 lib/x86_64/libxul.so
   179977  Defl:N64862  64% 2010-01-01 00:00 0ae40655  META-
 INF/TBA_ALPH.SF
 1791  Defl:N 1522  15% 2010-01-01 00:00 9789b962  META-
 INF/TBA_ALPH.RSA
   179850  Defl:N64218  64% 2010-01-01 00:00 171cbda6  META-
 INF/MANIFEST.MF
 }}}

 I don't know what change was introduced between `a7` and `a8`, but there
 are a lot of files that changed between them.

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

Re: [tor-bugs] #32239 [Internal Services/Tor Sysadmin Team]: setup a cache frontend for the blog

[Tor Bug Tracker & Wiki]

#32239: setup a cache frontend for the blog
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32090   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> design docs in https://help.torproject.org/tsa/howto/cache/
>
> launch checklist:
>
>  1. alternatives listing and comparison (done)
>  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
>  3. benchmark the different alternatives (done, ATS and nginx comparable)
>  4. setup secondary node with Puppet, say `cache-02.tpo` (in progress,
> missing puppet config)
>  4. validation benchmark against both nodes
>  5. lower DNS to 300 seconds, wait an hour
>  6. flip DNS to the cache node, wait and monitor for 5 minutes
>  7. raise DNS back to 1h if all goes well.
>
> Disaster recovery:
>
>  1. flip DNS back to pantheon

New description:

 design docs in https://help.torproject.org/tsa/howto/cache/

 launch checklist:

  1. alternatives listing and comparison (done)
  2. deploy a test virtual machine by hand, say `cache-01.tpo` (done)
  3. benchmark the different alternatives (done, ATS and nginx comparable)
  4. setup secondary node with Puppet, say `cache-02.tpo` (done)
  4. validation benchmark against both nodes (partial)
  5. lower DNS to 300 seconds, wait an hour (set TTL to 10min, waiting)
  6. flip DNS to the cache node, wait and monitor for 5 minutes
  7. raise DNS back to 1h if all goes well.

 Disaster recovery:

  1. flip DNS back to pantheon

--

Comment (by anarcat):

 new node is up and works, configured with puppet and the new nginx module.

 copied the cipher suite from the apache config, but i'm not sure about
 that, so I opened #32351 to followup on the suite in apache too.

 next step is to deploy on the original node with puppet, run sanity tests
 against both nodes, then flip the switch. whoohoo!

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:5 sisbell]:
 > We've seen the omni.ja problem before. The original approach was to just
 delete and add what we didn't need or needed respectively to the final
 apk. This meant, we weren't unzipping and zipping the apk. With the
 ApkTool approach for reproducibility, it's repackaging without the correct
 compression. So I suspect its a problem there.

 It seems this is due to unzipping and then zipping the entire archive.
 `zip` decides if a file should be `stored` or deflated automatically. The
 man page says
 {{{
 zip automatically chooses the better of the two (deflation or store or, if
bzip2 is selected, bzip2 or store) for each file to be compressed.
 }}}

 We can ignore the `bzip2` part of that.

 One terribly hacky solution is using the current patch, but then deleting
 `assets/omni.ja` from the apk and then re-adding it using `zip -Z store
 assets/omni.ja`, effectively forcing zip not deflating omni.ja. I don't
 remember the details of #31564 well enough right now to remember if there
 is a better alternative right now.

 I worry there are other bugs lurking as a result of our unzip/zip, but I
 don't have a better solution right now.

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:4 Horizon78]:
 > Also affected is the function to change the language! ... The error is
 reproducible! ... Crashes every time you go to settings to change the
 language! ... Please fix !!!  thanks
 Yes, sorry if that wasn't clear, that is the purpose of 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

[tor-bugs] #32351 [Internal Services/Tor Sysadmin Team]: review our ssl ciphers suite

[Tor Bug Tracker & Wiki]

#32351: review our ssl ciphers suite
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We currently use magic incantation from the Mozilla SSL observatory in our
 Apache (and now nginx, see #32239) installations. We should review it and
 see if it's still relevant. It seems we're using the suites as per the
 Mozilla observatory, but since we're upgrading to buster, it might be
 worth upgrading our suite a little.

 The documentation in the file mentions those URLs:

 https://mozilla.github.io/server-side-tls/ssl-config-
 generator/?server=apache-2.4.25=1.0.2l=yes=intermediate
 https://mozilla.github.io/server-side-tls/ssl-config-
 generator/?server=apache-2.4.25=1.1.0=no=intermediate

 But that's *two* lists... maybe what we have is the merged one?

 In any case, this probably needs a kick. The list was created in 2014 and
 last touched in 2018, according to the comments in the apache config.

 Unless we have per openssl-version configs, this will have to wait until
 #29399 is done at least.

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

Re: [tor-bugs] #31028 [Circumvention/Snowflake]: Migrate away from the custom websocket library

[Tor Bug Tracker & Wiki]

#31028: Migrate away from the custom websocket library
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+--

Comment (by cohosh):

 It's looking good. I left two comments on the commit.

 Should we move to the Gorilla websocket library for the proxy-go instances
 as well? The [https://godoc.org/golang.org/x/net/websocket GoDoc] for the
 x/net websocket package suggests Gorilla since it is more actively
 maintained.

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

Re: [tor-bugs] #31028 [Circumvention/Snowflake]: Migrate away from the custom websocket library

[Tor Bug Tracker & Wiki]

#31028: Migrate away from the custom websocket library
-+---
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+---
Changes (by cohosh):

 * status:  needs_review => needs_information


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

Re: [tor-bugs] #31371 [Core Tor/Tor]: hs: Add DoS defense counter to DoS heartbeat message

[Tor Bug Tracker & Wiki]

#31371: hs: Add DoS defense counter to DoS heartbeat message
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 042-deferred-20190918  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
   |  Sponsor27-must
---+---
Changes (by dgoulet):

 * status:  assigned => needs_review
 * reviewer:   => asn


Comment:

 Branch: `ticket31371_043_01`
 PR: https://github.com/torproject/tor/pull/1491

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

Re: [tor-bugs] #32250 [Applications/Tor Browser]: letterboxing: backport bugzilla 1546832

[Tor Bug Tracker & Wiki]

#32250: letterboxing: backport bugzilla 1546832
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-fingerprinting-|  Actual Points:  0.1
  resolution, tbb-9.0.1-can, |
  TorBrowserTeam201910R, GeorgKoppen201910   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Replying to [comment:4 gk]:
 > ...or later into 9.0.2 after baking a bit in 9.5a2

 Let it bake. Stable users are already rattled - let's not introduce the
 findbar causing letterbox changes too soon

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 We've seen the omni.ja problem before. The original approach was to just
 delete and add what we didn't need or needed respectively to the final
 apk. This meant, we weren't unzipping and zipping the apk. With the
 ApkTool approach for reproducibility, it's repackaging without the correct
 compression. So I suspect its a problem 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] #32020 [Core Tor/Tor]: hsv3: Client do not report failing circuit back into HS subsystem

[Tor Bug Tracker & Wiki]

#32020: hsv3: Client do not report failing circuit back into HS subsystem
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-client  |  Actual Points:  1
Parent ID:  #30200  | Points:  1
 Reviewer:  asn |Sponsor:  Sponsor27-must
+

Comment (by dgoulet):

 Replying to [comment:5 asn]:
 > Replying to [comment:3 dgoulet]:
 > > Related is #26806 which mentions that possibly because the HSv3 client
 is not noticing the introduction timeout (as in the ACK never came back),
 we resend onto that same intro point. Good or bad?
 >
 >
 > Hmm, questions and answers:
 >
 > 1) Why doesn't the ACK or NACK come to the client? Is it because the
 intro point never sent it (why?)? Or because we timeout before receiving
 it? Or just general Tor network SNAFU?

 SNAFU is probably the answer. Circuit collapsing, timing out, etc...

 >
 > 2) If the above happens, why would the client decide to resend on the
 same intro point and same circuit? Is this an explicit decision?

 It doesn't in theory. Depending on the SNAFU (see patch I did), we either
 flag the intro point in the failure cache (see patch I did) or we go on
 with our lives maybe retrying a new one.

 > 3) Regarding "Good or bad?" I would say it's bad-ish because if the NACK
 never came back, I would prefer to retry a different intro point since
 that one might be suffering networking issues, or being overloaded, or
 downright maliciously DoSing the service.

 Yes, in theory, that is what is suppose to happen. The patch I did would
 fix this that is note down the intro point in the failure cache.

 >
 > PS: #26806 mentions "rendezvous circuits" in the title, but I think it
 should be intro circuits

 Yes.

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

Re: [tor-bugs] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by gaba):

 * sponsor:   => Sponsor28


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

Re: [tor-bugs] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * points:   => 3


Comment:

 Just estimating this to be 3 points for now since we need to do some
 investigation into what is happening 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] #32020 [Core Tor/Tor]: hsv3: Client do not report failing circuit back into HS subsystem

[Tor Bug Tracker & Wiki]

#32020: hsv3: Client do not report failing circuit back into HS subsystem
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-client  |  Actual Points:  1
Parent ID:  #30200  | Points:  1
 Reviewer:  asn |Sponsor:  Sponsor27-must
+

Comment (by asn):

 Replying to [comment:3 dgoulet]:
 > Related is #26806 which mentions that possibly because the HSv3 client
 is not noticing the introduction timeout (as in the ACK never came back),
 we resend onto that same intro point. Good or bad?


 Hmm, questions and answers:

 1) Why doesn't the ACK or NACK come to the client? Is it because the intro
   point never sent it (why?)? Or because we timeout before receiving it?
 Or just
   general Tor network SNAFU?

 2) If the above happens, why would the client decide to resend on the same
   intro point and same circuit? Is this an explicit decision?

 3) Regarding "Good or bad?" I would say it's bad-ish because if the NACK
 never
   came back, I would prefer to retry a different intro point since that
 one
   might be suffering networking issues, or being overloaded, or downright
   maliciously DoSing the service.

 PS: #26806 mentions "rendezvous circuits" in the title, but I think it
 should be intro circuits

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

Re: [tor-bugs] #27604 [Applications/Tor Browser]: Relocating the Tor Browser directory is broken with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27604: Relocating the Tor Browser directory is broken with Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:  3
  tbb-8.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 I can't reproduce... Which exact files did you remove to get these?

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

Re: [tor-bugs] #32250 [Applications/Tor Browser]: letterboxing: backport bugzilla 1546832

[Tor Bug Tracker & Wiki]

#32250: letterboxing: backport bugzilla 1546832
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-fingerprinting-|  Actual Points:  0.1
  resolution, tbb-9.0.1-can, |
  TorBrowserTeam201910R, GeorgKoppen201910   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 ff68-esr, tbb-fingerprinting-resolution, tbb-9.0.1-can,
 TorBrowserTeam201910
 =>
 ff68-esr, tbb-fingerprinting-resolution, tbb-9.0.1-can,
 TorBrowserTeam201910R, GeorgKoppen201910
 * status:  new => needs_review
 * points:   => 0.1
 * actualpoints:   => 0.1


Comment:

 Thanks! I cherry-picked both patches in my `bug_32250`
 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_32250).
 Not sure yet whether they should make it directly into 9.0.1 or later into
 9.0.2 after baking a bit in 9.5a2.

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

Re: [tor-bugs] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Horizon78):

 Also affected is the function to change the language! ... The error is
 reproducible! ... Crashes every time you go to settings to change the
 language! ... Please fix !!!  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] #32318 [Applications/Tor Browser]: Backport support for IPv6 addresses in firstparty domain isolation (bug 1534339)

[Tor Bug Tracker & Wiki]

#32318: Backport support for IPv6 addresses in firstparty domain isolation (bug
1534339)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910R,   |  Actual Points:  0.1
  GeorgKoppen201910  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  TorBrowserTeam201910, GeorgKoppen201910 =>
 TorBrowserTeam201910R, GeorgKoppen201910
 * points:   => 0.1
 * actualpoints:   => 0.1


Comment:

 `bug_32318` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_32318) has the backport. That's something for
 our alpha release first, 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] #32342 [Applications/Tor Browser]: Tor Browser for Android crashes when opening the locale pane in the settings

[Tor Bug Tracker & Wiki]

#32342: Tor Browser for Android crashes when opening the locale pane in the
settings
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-mobile, tbb-crash,   |  Actual Points:
  tbb-9.0-issues, tbb-regression,|
  tbb-9.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 `9.0a7`:
 {{{
  1174440  Defl:N   417613  64% 2000-01-01 00:00 3169aef4
 lib/x86_64/libmozglue.so
  1781088  Defl:N   593355  67% 2000-01-01 00:00 dcacddb5
 lib/x86_64/libmozavcodec.so
  1858081  Defl:N  1787604   4% 2000-01-01 00:00 6e9c0248
 assets/distribution/extensions/https-everywhere-...@eff.org.xpi
  1884528  Defl:N   912276  52% 2000-01-01 00:00 025746a3
 lib/x86_64/libnss3.so
  2339663  Defl:X   269250  89% 2010-01-01 00:00 bb2bb5ce
 assets/common/geoip6
  4073678  Defl:X  1190281  71% 2010-01-01 00:00 2c54d862
 assets/common/geoip
  5720092  Defl:X  2443472  57% 2010-01-01 00:00 401195d9  classes.dex
  7105248  Defl:N  2391049  66% 2000-01-01 00:00 2bb41c2d
 lib/x86_64/libObfs4proxy.so
  7478968  Defl:N  2698159  64% 2000-01-01 00:00 f391dcb9
 lib/x86_64/libTor.so
 10836161  Stored 10836161   0% 2010-01-01 00:00 71404561  assets/omni.ja
 86656560  Defl:N 32635129  62% 2000-01-01 00:00 355d0169
 lib/x86_64/libxul.so
 137422584 61169376  56%1561 files
 }}}

 `9.0a8`:
 {{{
  1174440  Defl:N   417612  64% 2000-01-01 00:00 fa4ea2be
 lib/x86_64/libmozglue.so
  1781088  Defl:N   593362  67% 2000-01-01 00:00 e0620690
 lib/x86_64/libmozavcodec.so
  1858081  Defl:N  1787604   4% 2000-01-01 00:00 6e9c0248
 assets/distribution/extensions/https-everywhere-...@eff.org.xpi
  1884528  Defl:N   912275  52% 2000-01-01 00:00 9f197d32
 lib/x86_64/libnss3.so
  2339663  Defl:N   295431  87% 2000-01-01 00:00 bb2bb5ce
 assets/common/geoip6
  4073678  Defl:N  1191956  71% 2000-01-01 00:00 2c54d862
 assets/common/geoip
  5720064  Defl:N  2453573  57% 2000-01-01 00:00 be25d81c  classes.dex
  7105248  Defl:N  2391049  66% 2000-01-01 00:00 2bb41c2d
 lib/x86_64/libObfs4proxy.so
  7478968  Defl:N  2698159  64% 2000-01-01 00:00 f391dcb9
 lib/x86_64/libTor.so
 10866315  Defl:N 10307038   5% 2000-01-01 00:00 152db749  assets/omni.ja
 86656560  Defl:N 32634495  62% 2000-01-01 00:00 0dec3529
 lib/x86_64/libxul.so
 137614012 59830866  57%1561 files
 }}}

 So, comparing `9.0a7` and `9.0a8` show omni.ja was simply `stored` in
 `9.0a7` (indicating it was already compressed), while it was compressed
 using deflate in `9.0a8`. We can see the size of the apk decreased, as
 well (presumably because an inflated omni.ja allowed higher overall
 compression of the apk):
 {{{

 -rw-r--r-- 1 sysrqb sysrqb 59M Oct 31 15:53 tor-browser-9.0a7-android-
 x86_64-multi.apk
 -rw-r--r-- 1 sysrqb sysrqb 58M Oct 31 15:53 tor-browser-9.0a8-android-
 x86_64-multi.apk
 }}}

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

Re: [tor-bugs] #31028 [Circumvention/Snowflake]: Migrate away from the custom websocket library

[Tor Bug Tracker & Wiki]

#31028: Migrate away from the custom websocket library
-+--
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+--
Changes (by cohosh):

 * reviewer:   => cohosh


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

Re: [tor-bugs] #25601 [Circumvention/Snowflake]: Multiplex - one snowflake proxy should be able to support multiple clients

[Tor Bug Tracker & Wiki]

#25601: Multiplex - one snowflake proxy should be able to support multiple 
clients
-+-
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, anti-censorship-  |  Actual Points:
  roadmap-september  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-

Comment (by cohosh):

 I should add that when we decide we want to increase the number of clients
 for browser proxies, we will probably want to make UI changes to allow
 users to modify the config. Again, I don't want to push out those changes
 yet until we sort out some of the network health issues we're seeing.

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

Re: [tor-bugs] #25601 [Circumvention/Snowflake]: Multiplex - one snowflake proxy should be able to support multiple clients

[Tor Bug Tracker & Wiki]

#25601: Multiplex - one snowflake proxy should be able to support multiple 
clients
-+-
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, anti-censorship-  |  Actual Points:
  roadmap-september  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-
Changes (by cohosh):

 * status:  new => needs_review


Comment:

 Okay so it turns out the multiplexing just works now that #31310 is out
 the way and we're using the existence of proxypairs to signal how many
 slots we have.

 I did just a small touch-up of the code
 
[https://github.com/cohosh/snowflake/commit/300a23c6a0071a910ee3b56f7bf14e4f9529ee3f
 here] to go with a more meaningful variable name that was going unused.

 I tested this in snowbox by setting the `maxNumClients` to values other
 than `1` and it works great. However, I don't think we should change this
 yet as our problems right now are definitely not that we have too few
 browser-based proxies.

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

Re: [tor-bugs] #32321 [Applications/Tor Browser]: https://mitmdetection.services.mozilla.com/ is contacted over catch-all circuit

[Tor Bug Tracker & Wiki]

#32321: https://mitmdetection.services.mozilla.com/ is contacted over catch-all
circuit
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:  0.1
  linkability, TorBrowserTeam201910R,|
  GeorgKoppen201910  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-linkability,
 TorBrowserTeam201910R =>
 tbb-9.0-issues, tbb-9.0.1-can, tbb-linkability, TorBrowserTeam201910R,
 GeorgKoppen201910


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

Re: [tor-bugs] #32321 [Applications/Tor Browser]: https://mitmdetection.services.mozilla.com/ is contacted over catch-all circuit

[Tor Bug Tracker & Wiki]

#32321: https://mitmdetection.services.mozilla.com/ is contacted over catch-all
circuit
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:  0.1
  linkability, TorBrowserTeam201910R |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-linkability =>
 tbb-9.0-issues, tbb-9.0.1-can, tbb-linkability, TorBrowserTeam201910R
 * status:  new => needs_review
 * points:   => 0.1
 * actualpoints:   => 0.1


Comment:

 I think it's fine do disable that ping to Mozilla right now. We should
 think generally about improving our certificate error pages though. #19119
 has some ideas here.

 `bug_32321` (https://gitweb.torproject.org/user/gk/tor-
 browser.git/commit/?h=bug_32321=a04d0f9b5976bf2802aa5bd78bcce4d2855b3995)
 has a patch for review.

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

Re: [tor-bugs] #19119 [Applications/Tor Browser]: Repurpose block-malicious-sites-checkbox on TLS error page in Tor Browser

[Tor Bug Tracker & Wiki]

#19119: Repurpose block-malicious-sites-checkbox on TLS error page in Tor 
Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => network-health


Comment:

 #32321 deals with Mozilla's MitM check pref. Might be interesting to think
 about that for ourselves.

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

Re: [tor-bugs] #31310 [Circumvention/Snowflake]: Refactor/remove proxy-pair state machine in webextension

[Tor Bug Tracker & Wiki]

#31310: Refactor/remove proxy-pair state machine in webextension
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

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


Comment:

 Merged in `64b66c855`: https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=64b66c855fe35d2e56fca7510e913482cdb85793

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

Re: [tor-bugs] #32186 [Applications/Tor Check]: Allow use of external exit list via HTTPS

[Tor Bug Tracker & Wiki]

#32186: Allow use of external exit list via HTTPS
+-
 Reporter:  irl |  Owner:  arlolra
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  exitscanner |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by gaba):

 * keywords:   => exitscanner


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

Re: [tor-bugs] #29654 [Metrics/Exit Scanner]: Initial MVP for new exit scanner

[Tor Bug Tracker & Wiki]

#29654: Initial MVP for new exit scanner
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2 exitscanner  |  Actual Points:
Parent ID:  #29650   | Points:  6
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

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


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

Re: [tor-bugs] #32262 [Metrics/Exit Scanner]: MS: Implement an ExitSpider class

[Tor Bug Tracker & Wiki]

#32262: MS: Implement an ExitSpider class
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:  exitscanner   |  Actual Points:
Parent ID:  #29654| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gaba):

 * keywords:   => exitscanner


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

Re: [tor-bugs] #29650 [Metrics/Exit Scanner]: Rewrite exit scanner to produce exit lists according to new format

[Tor Bug Tracker & Wiki]

#29650: Rewrite exit scanner to produce exit lists according to new format
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2 exitscanner  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

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


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

Re: [tor-bugs] #32190 [Core Tor/Tor]: Send a control port event when a stream enters the controller_wait state

[Tor Bug Tracker & Wiki]

#32190: Send a control port event when a stream enters the controller_wait state
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  exitscanner   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gaba):

 * keywords:   => exitscanner


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

Re: [tor-bugs] #31204 [Metrics/CollecTor]: Extend file objects in index.json to include descriptor types, publication times, and file digests

[Tor Bug Tracker & Wiki]

#31204: Extend file objects in index.json to include descriptor types, 
publication
times, and file digests
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 LGTM. Tested with a local build of metrics-lib with a modified
 junittest.policy, I could test again once metrics-{base,lib} changes are
 made and released, but it's probably fine.

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

Re: [tor-bugs] #32231 [Metrics/CollecTor]: Lost some metrics due to broker host migration

[Tor Bug Tracker & Wiki]

#32231: Lost some metrics due to broker host migration
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cohosh):

 Ideally, we would only collect stats from the broker that people are
 actually using, which right now is the old broker which the freehaven.net
 snowflake domains point to.

 Actually, we can probably go ahead and fix this now. How hard would it be
 to point CollecTor to snowflake-bro...@freehaven.net now and replace the
 metrics files from 2019-10-16 onwards with files from that host?

 When we finally move the freehaven.net domain to point to the new broker,
 we just need to make sure we don't overwrite these old files again (or we
 could copy over the metrics files to the new host when we do the switch).

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

Re: [tor-bugs] #32231 [Metrics/CollecTor]: Lost some metrics due to broker host migration

[Tor Bug Tracker & Wiki]

#32231: Lost some metrics due to broker host migration
---+--
 Reporter:  cohosh |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 So, the issue is that there are two brokers running at the same time and
 you want both metrics to be archived by CollecTor?

 Here's what I found in CollecTor's tarballs from the past few weeks:

 {{{
 $ grep -R "snowflake-ips-total" * | sort | tail -n20
 snowflakes-2019-10/10/2019-10-10-14-18-42-snowflake-stats:snowflake-ips-
 total 3951
 snowflakes-2019-10/12/2019-10-12-14-29-08-snowflake-stats:snowflake-ips-
 total 3481
 snowflakes-2019-10/13/2019-10-13-14-29-08-snowflake-stats:snowflake-ips-
 total 3108
 snowflakes-2019-10/14/2019-10-14-14-29-08-snowflake-stats:snowflake-ips-
 total 3409
 snowflakes-2019-10/15/2019-10-15-14-29-08-snowflake-stats:snowflake-ips-
 total 3848
 snowflakes-2019-10/16/2019-10-16-14-29-08-snowflake-stats:snowflake-ips-
 total 3925
 snowflakes-2019-10/16/2019-10-16-16-28-15-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/17/2019-10-17-14-29-08-snowflake-stats:snowflake-ips-
 total 4106
 snowflakes-2019-10/17/2019-10-17-16-28-15-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/18/2019-10-18-19-44-19-snowflake-stats:snowflake-ips-
 total 1
 snowflakes-2019-10/19/2019-10-19-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/20/2019-10-20-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/21/2019-10-21-19-44-19-snowflake-stats:snowflake-ips-
 total 1
 snowflakes-2019-10/22/2019-10-22-19-44-19-snowflake-stats:snowflake-ips-
 total 1
 snowflakes-2019-10/23/2019-10-23-19-44-19-snowflake-stats:snowflake-ips-
 total 1
 snowflakes-2019-10/24/2019-10-24-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/25/2019-10-25-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/26/2019-10-26-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/27/2019-10-27-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 snowflakes-2019-10/28/2019-10-28-19-44-19-snowflake-stats:snowflake-ips-
 total 0
 }}}

 It looks like you added the new broker around 2019-10-16 and had the old
 broker publish its stats until 2019-10-17.

 If archiving both files is the plan, I wonder how to tell the two apart
 from stats contents. There's no identity or nickname of any kind in the
 files. Would you want to include such a thing?

 Or are you asking to switch from one broker to the other, stats-wise, by
 (manually) deleting files, so that files from the old broker end on day
 '''x''' and files from the new broker start on day '''x+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] #31591 [Applications/Tor Browser]: Feature review for ESR68

[Tor Bug Tracker & Wiki]

#31591: Feature review for ESR68
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:  6
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:6 mikeperry]:
 > Ok I looked through FF68's dev docs in detail. The only thing that
 struck me as remotely concerning was the potential ability to build high
 precision timers for performance fingerprinting out of the Close Caption
 https://developer.mozilla.org/en-
 US/docs/Web/API/TextTrack/cuechange_event.. I don't think we have gone
 down that rabbithole of trying to eliminate such timers, right? And it's
 not even clear that the accuracy of this timer would be very high in the
 first place, so it might not even be possible.

 Yeah, as Tom said we did no go down that rabbit hole yet. I think we have
 #16110 for the general area and now #32350 for your issue in particular.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32350 [Applications/Tor Browser]: Think about whether Close Captions can help creating high-performance timers

[Tor Bug Tracker & Wiki]

#32350: Think about whether Close Captions can help creating high-performance
timers
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-fingerprinting-
 Severity:  Normal   |  time-highres
Actual Points:   |  Parent ID:  #16110
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In Firefox 68 https://developer.mozilla.org/en-
 US/docs/Web/API/TextTrack/cuechange_event landed which might help in
 constructing highres-timers (see: comment:6:ticket:31591).

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

Re: [tor-bugs] #31591 [Applications/Tor Browser]: Feature review for ESR68

[Tor Bug Tracker & Wiki]

#31591: Feature review for ESR68
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Here come my notes for Firefox 61-67 (inclusive) dev-doc reviews:

 The developer docs can be found at https://developer.mozilla.org/en-
 US/docs/Mozilla/Firefox/Releases/XX (Where "XX" is the actual Firefox
 version to be investigated).

 There was nothing concerning for Firefox 61 and 62.

 For Firefox 63 we have the Media Capabilities API
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1409664) which we addressed
 in #13543. I made a note on #16678 as changes might affect this bug and
 filed an investigated #31954. I skimmed
 https://bugzilla.mozilla.org/show_bug.cgi?id=1349799 and think the WebGL
 power preference in this bug is not a problem for us.

 Nothing found for Firefox 64.

 There are some items for Firefox 65: RelativeTimeFormat
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1504334) which got
 investigated in #31985. Then we have the Streams API (#31997), Storage
 Access API (#32002) and new WebGL extensions (#32013)

 Nothing found for Firefox 66.

 New WebGL extension in Firefox 67. I opened #32057 and investigated the
 new feature.

 All in all I think we are not in bad shape 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] #32194 [Metrics/Library]: NetworkStatusEntryImpl#parseSLine (and probably other methods) is not thread-safe

[Tor Bug Tracker & Wiki]

#32194: NetworkStatusEntryImpl#parseSLine (and probably other methods) is not
thread-safe
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Replying to [comment:2 irl]:
 > LGTM.

 Great! Merging.

 > I have noticed that the Onionoo updater is finishing very close to the
 next start time. We're seeing that sometimes it is taking too long (hence
 we get a pile of alerts from Nagios that the time is older than 2 hours,
 which get resolved quite quickly). We should be thinking about thread-
 safety in any new code to avoid this being a problem later.

 Ah, in that specific case we don't have to worry about thread-safety,
 because we're never running two Onionoo updaters at the same time. We're
 using
 
[https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledExecutorService.html
 #scheduleAtFixedRate-java.lang.Runnable-long-long-
 java.util.concurrent.TimeUnit- this method] for scheduling runs. Its
 documentation says: ''"If any execution of this task takes longer than its
 period, then subsequent executions may start late, but will not
 concurrently execute."'' That doesn't mean we shouldn't be looking into
 why executions take so long. But at least that doesn't cause new trouble
 with concurrent executions.

 Closing this ticket. 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] #32322 [Metrics/Onionoo]: Onionoo documentation error: "TCP ports are not sanitized"

[Tor Bug Tracker & Wiki]

#32322: Onionoo documentation error: "TCP ports are not sanitized"
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Good catch. Fixed. Thanks! Closing.

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

Re: [tor-bugs] #32194 [Metrics/Library]: NetworkStatusEntryImpl#parseSLine (and probably other methods) is not thread-safe

[Tor Bug Tracker & Wiki]

#32194: NetworkStatusEntryImpl#parseSLine (and probably other methods) is not
thread-safe
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

 I have noticed that the Onionoo updater is finishing very close to the
 next start time. We're seeing that sometimes it is taking too long (hence
 we get a pile of alerts from Nagios that the time is older than 2 hours,
 which get resolved quite quickly). We should be thinking about thread-
 safety in any new code to avoid this being a problem later.

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

Re: [tor-bugs] #32020 [Core Tor/Tor]: hsv3: Client do not report failing circuit back into HS subsystem

[Tor Bug Tracker & Wiki]

#32020: hsv3: Client do not report failing circuit back into HS subsystem
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-client  |  Actual Points:  1
Parent ID:  #30200  | Points:  1
 Reviewer:  asn |Sponsor:  Sponsor27-must
+
Changes (by dgoulet):

 * cc: asn (removed)
 * status:  assigned => needs_review
 * reviewer:   => asn
 * actualpoints:   => 1


Comment:

 Branch: `ticket32020_043_01`
 PR: https://github.com/torproject/tor/pull/1490

 @asn: The initial commits are mostly moving and refactoring code on how we
 handle the circuit cleanup. It is not that simple so let me know if the
 approach is sensible. But overall, there needs to be nuanced cleanup
 between close/free/repurpose.

 Also, out of this work, I found #32349 in v2.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32349 [Core Tor/Tor]: hs-v2: Intro point circuit TIMEOUT failure is not reported

[Tor Bug Tracker & Wiki]

#32349: hs-v2: Intro point circuit TIMEOUT failure is not reported
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  035-backport, 040-backport,
 Severity:  Normal   |  041-backport, 042-backport, tor-hs
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:  asn
  Sponsor:   |
  Sponsor27-can  |
-+-
 This was found while I was working on #32020.

 For v2, we report a TIMEOUT circuit failure within
 `circuit_about_to_free()`. The following code is the snippet on how we
 check if the circuit timed out:

 {{{
 int reason = circ->marked_for_close_reason;
 int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
 }}}

 However, in `circuit_mark_for_close_()`, if the circuit is an origin one,
 which is the case for all HS client circuit, the `marked_for_close_reason`
 is set to `END_CIRC_REASON_NONE` so we don't send back that reason back
 within the destroy cell.

 The fix is that we should be looking at `marked_for_close_orig_reason`
 instead.

 We need to backport 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] #31899 [Applications/Tor Browser]: Hook .onion with URI_IS_POTENTIALLY_TRUSTWORTHY?

[Tor Bug Tracker & Wiki]

#31899: Hook .onion with URI_IS_POTENTIALLY_TRUSTWORTHY?
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21728| Points:
 Reviewer:|Sponsor:
--+--
Description changed by gk:

Old description:

> There is the idea that the check whether a particular origin is
> trustworthy should consider the URI flags. We should think about how that
> fixes into our particular model of declaring .onions to a potentially
> trustworthy origin.
>
> See: https://bugzilla.mozilla.org/show_bug.cgi?id=1328695.

New description:

 There is the idea that the check whether a particular origin is
 trustworthy should consider the URI flags. We should think about how that
 fits into our particular model of declaring .onions to a potentially
 trustworthy origin.

 See: https://bugzilla.mozilla.org/show_bug.cgi?id=1328695.

--

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

Re: [tor-bugs] #27307 [Applications/Tor Browser]: NoScript marks HTTP Onion as insecure

[Tor Bug Tracker & Wiki]

#27307: NoScript marks HTTP Onion as insecure
+--
 Reporter:  cypherpunks3|  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Minor   | Resolution:  fixed
 Keywords:  noscript, TorBrowserTeam201910  |  Actual Points:
Parent ID:  #21728  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Fixed with the bump to 11.0.4 (commit
 6cbbd55840577c4d3ab5581e76cffde26a5f5ff6 and
 8623975e60c99b2a526bbda133168d7de5f8d329 on tor-browser-build's maint-9.0
 and master branches), thanks!

 The issues mentioned in my two previous comments are still visible,
 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] #21004 [Applications/Tor Browser]: "JavaScript is disabled by default on all non-HTTPS sites" option shouldn't block JS on hidden services

[Tor Bug Tracker & Wiki]

#21004: "JavaScript is disabled by default on all non-HTTPS sites" option 
shouldn't
block JS on hidden services
-+-
 Reporter:  righnaw  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security-slider, noscript,   |  Actual Points:
  TorBrowserTeam201910R  |
Parent ID:  #21728   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-security-slider, noscript => tbb-security-slider,
 noscript, TorBrowserTeam201910R
 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed with the bump to 11.0.4 (commit
 6cbbd55840577c4d3ab5581e76cffde26a5f5ff6 and
 8623975e60c99b2a526bbda133168d7de5f8d329 on `tor-browser-build`'s
 `maint-9.0` and `master` branches), 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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328, |
  035-backport-maybe, 040-backport-maybe, 041|
  -backport-maybe, 042-backport-maybe,   |
  BugSmashFund   |
Parent ID:  #2   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * parent:   => #2


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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328, |
  035-backport-maybe, 040-backport-maybe, 041|
  -backport-maybe, 042-backport-maybe,   |
  BugSmashFund   |
Parent ID:  #29995   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

 * parent:  #2 => #29995


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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328, |
  035-backport-maybe, 040-backport-maybe, 041|
  -backport-maybe, 042-backport-maybe,   |
  BugSmashFund   |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 Replying to [comment:28 arma]:
 > Replying to [comment:15 dgoulet]:
 > > It should be allowed to have more than once the same intro point in
 the descriptor.
 >
 > Why should this be allowed? Is there any benefit to it?
 >
 > Handling it correctly sounds good, but disallowing it in the spec sounds
 good too right?

 Yeah I said that solely based on the fact that the spec doesn't
 specifically mention that it is not allowed.

 We could easily clarify the spec there and then move the code to consider
 any descriptor with the same intro point a "bad descriptor". Not much
 incentive on my part though to make it happen "soon" :P.

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

Re: [tor-bugs] #27604 [Applications/Tor Browser]: Relocating the Tor Browser directory is broken with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27604: Relocating the Tor Browser directory is broken with Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:  3
  tbb-8.0.1-can, TorBrowserTeam201910|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-8.0-issues, tbb-regression, tbb-8.0.1-can,
 TorBrowserTeam201910R => tbb-8.0-issues, tbb-regression,
 tbb-8.0.1-can, TorBrowserTeam201910


Comment:

 Replying to [comment:32 acat]:
 > Patch for review: https://github.com/acatarineu/tor-browser/commit/27604
 >
 > I think there are (at least) three different issues here:
 >
 > One is the problem of extensions being broken that mcs mentioned, which
 I think was introduced by
 https://bugzilla.mozilla.org/show_bug.cgi?id=1512436. More concretely, the
 problem seems to be the new `rootURI` field in `addonStartup.json` which
 is absolute, unlike the `path` one which is serialized as relative:
 https://searchfox.org/mozilla-
 
esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#555.
 I think this was needed to have built-in addons with `resource://`
 `rootURI` like `resource://gre/modules/themes/default/`. Fixed this by
 always overriding  it [https://searchfox.org/mozilla-
 
esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#488
 here] if `this.file` exists (should not happen with addons with
 `resource://` rootURIs).
 >
 > The other is some special treatment that langpacks get due to
 https://bugzilla.mozilla.org/show_bug.cgi?id=1492459. These are flagged as
 `missing` early [https://searchfox.org/mozilla-
 
esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#502
 here] (`currentModifiedTime` is set [https://searchfox.org/mozilla-
 esr68/source/toolkit/mozapps/extensions/AddonManagerStartup.cpp#445 here]
 only for langpacks) if the (old) path of the extension xpi does not exist.
 If that's the case the langpack is removed in https://searchfox.org
 /mozilla-
 
esr68/rev/715f10032bb8be971ff0e9846e12be58afad4950/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#3143.
 That  seems to fallback to English, but on browser restart it's completely
 broken, showing the same error message mentioned in comment:29 and in
 bugzilla.  I'm not so sure what's the best way to fix this, in the
 proposed patch I'm checking for the (new) extension file existing before
 flagging it as missing.
 >
 > Third is the issue of `extensions.json` (and possibly `webext.sc.lz4`)
 paths not being updated, but I'm not so sure this has functionality impact
 if the two previous issues are fixed. In any case, I think making
 `scanForChanges` return `true` when the path of some addon location has
 changed will do the trick here and trigger an update of `extensions.json`.
 I verified that `webext.sc.lz4` paths are also updated, although I did not
 investigate what exactly in the code is updating the latter.
 >
 > With the patch I cannot reproduce the issues anymore, verified on Linux
 and Windows. I also verified that a profile which is in the bad state of
 comment:29 is fixed.
 >
 > I think it's worth filing bugzillas or updating the existing ones and
 try to get this fixed in Firefox (and also get some feedback on the
 suggested patches).

 Yes, please do update https://bugzilla.mozilla.org/show_bug.cgi?id=1429838
 so we can get some feedback here as well.

 That said this looks pretty good. One thing we should fix is getting
 {{{
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: 

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328, |
  035-backport-maybe, 040-backport-maybe, 041|
  -backport-maybe, 042-backport-maybe,   |
  BugSmashFund   |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by arma):

 Replying to [comment:15 dgoulet]:
 > It should be allowed to have more than once the same intro point in the
 descriptor.

 Why should this be allowed? Is there any benefit to it?

 Handling it correctly sounds good, but disallowing it in the spec sounds
 good too right?

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

Re: [tor-bugs] #32213 [Core Tor/Tor]: Phase 1: Disable minimal dirauth and relay options when those modules are disabled

[Tor Bug Tracker & Wiki]

#32213: Phase 1: Disable minimal dirauth and relay options when those modules 
are
disabled
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  4.5
  october|
Parent ID:  #31851   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-must
-+-
Changes (by teor):

 * actualpoints:  3.3 => 4.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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, tor-hs,|  Actual Points:  0.1
  034-triage-20180328, 034-removed-20180328, |
  035-backport-maybe, 040-backport-maybe, 041|
  -backport-maybe, 042-backport-maybe,   |
  BugSmashFund   |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

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


Comment:

 LGTM!

 I agree with you that v3 should be covered because of
 `intro_point_is_usable()` use in `client_get_random_intro()`.

 Merging!

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

Re: [tor-bugs] #32213 [Core Tor/Tor]: Phase 1: Disable minimal dirauth and relay options when those modules are disabled

[Tor Bug Tracker & Wiki]

#32213: Phase 1: Disable minimal dirauth and relay options when those modules 
are
disabled
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  3.3
  october|
Parent ID:  #31851   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-must
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 I'm still improving the test coverage, I think we can do a review on the
 code changes while that is happening.

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

Re: [tor-bugs] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

[Tor Bug Tracker & Wiki]

#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:5 atagar]:
 > > I imagine that the feature will be finalized in December
 >
 > Are we discussing this branch or something else? I expect to finish this
 branch within a week or so. HSv3 descriptor support will be part of Stem
 1.8.
 >

 That's true, what I meant is that there is still things to be done for the
 actual hsv3 support to be proper and complete. In particular, support for
 encoding legacy keys and the OPE scheme in the revision counter are
 definitely needed for the code to be useful. Plus I imagine that bugs will
 be found as I use the decoding/encoding functionality in stem, so even tho
 this will be merged soon, I imagine that the branch will actually be in
 good shape at some point in late November or early December.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32348 [Applications/Tor Browser]: Tor Browser 9 on Samsung S2 is not starting anymore

[Tor Bug Tracker & Wiki]

#32348: Tor Browser 9 on Samsung S2 is not starting anymore
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-9.0-issue, tbb-
 Severity:  Normal   |  regression, tbb-mobile
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 With the update to Tor Browser 9 a user on our blog
 [https://blog.torproject.org/comment/285128#comment-285128 reported] that
 the browser is not starting anymore on their Samsung S2 device (running
 Android 4.1.2). It just sits there after tapping the connect button.

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

Re: [tor-bugs] #32348 [Applications/Tor Browser]: Tor Browser 9 on Samsung S2 is not starting anymore

[Tor Bug Tracker & Wiki]

#32348: Tor Browser 9 on Samsung S2 is not starting anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issue, tbb-regression, tbb-  |  Actual Points:
  mobile |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Maybe related to #32331?

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

Re: [tor-bugs] #32345 [Applications/Tor Browser]: Tor Browser Bundle 9.0 Linux 32-bit won't launch

[Tor Bug Tracker & Wiki]

#32345: Tor Browser Bundle 9.0 Linux 32-bit won't launch
---+---
 Reporter:  sectua1|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-9.0-issue, tbb-9.0-regression  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * keywords:   => tbb-9.0-issue, tbb-9.0-regression
 * status:  new => needs_information
 * component:  Applications => Applications/Tor Browser
 * owner:  (none) => tbb-team


Comment:

 What error do you get if you launch it from the command line in your Tor
 Browser directory with `./start-tor-browser.desktop --debug`?

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