Re: [tor-bugs] #30500 [Circumvention/Censorship analysis]: Can the GFW still do DPI for "new" vanilla Tor?

[Tor Bug Tracker & Wiki]

#30500: Can the GFW still do DPI for "new" vanilla Tor?
---+--
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  Low|  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  gfw, china |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Are you saying Tor bridges / relays can look for those 65 ciphers, and
 refuse to continue in that case? :)

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 An operator just emailed me these relays:
 E4240508EFC308D01665A07BD98B8564740D3376
 1CD17CB202063C51C7DAD3BACEF87ECE81C2350F
 D1AFBF3117B308B6D1A7AA762B1315FD86A6B8AF
 6BA54D7805A44F63A75D70AFEC8D2DF6BA7BCAE0
 C87A4D8B534F78FDF0F4639B55F121401FEF259C
 745369332749021C6FAF100D327BC3BF1DF4707B
 D50101A2ABD09DC245F7E96C0818D003CDD62351
 3AFDAAD91A15B4C6A7686A53AA8627CA871FF491
 5BF17163CBE73D8CD9FDBE030C944EA05707DA93
 C36A434DB54C66E1A97A5653858CE36024352C4D

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

Re: [tor-bugs] #29285 [Circumvention/Pluggable transport]: Improve the PT spec and how PTs interface with Tor

[Tor Bug Tracker & Wiki]

#29285: Improve the PT spec and how PTs interface with Tor
-+-
 Reporter:  cohosh   |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2,  |  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by teor):

 We also want to be able to assign multiple addresses to each pluggable
 transport. For example, and IPv4 and IPv6 address.
 See #30953 for details.

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

Re: [tor-bugs] #30958 [Core Tor/Tor]: Stop removing the ed25519 signature when the extra-info file is too big

[Tor Bug Tracker & Wiki]

#30958: Stop removing the ed25519 signature when the extra-info file is too big
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 029-backport-|  Actual Points:  0.2
  maybe, 035-backport-maybe, 040-backport-   |
  maybe, 041-backport|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I re-did the master merge, and cherry-picked #30959 onto it.

 Please see my pull requests:
 * 0.2.9: https://github.com/torproject/tor/pull/1132

 Clean merges:
 * 0.3.5: https://github.com/torproject/tor/pull/1133
 * 0.4.0: https://github.com/torproject/tor/pull/1134
 * 0.4.1: https://github.com/torproject/tor/pull/1135

 Adds a commit with extre comments:
 * master: https://github.com/torproject/tor/pull/1136

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

Re: [tor-bugs] #30959 [Core Tor/Tor]: Add comments about the chunk format in extrainfo_dump_to_string()

[Tor Bug Tracker & Wiki]

#30959: Add comments about the chunk format in extrainfo_dump_to_string()
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-bridge, tor-pt  |  Actual Points:  0.1
Parent ID:  #30958  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by teor):

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


Comment:

 I cherry-picked this extra commit to #30958.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:30 teor]:
 > Replying to [comment:29 teor]:
 > > These relay operators sent me emails telling me they have fixed their
 relays:
 > > C6B656BA6BC16E31115A1B2D56396A53165F3408
 >
 > This relay's descriptor is out of date, I added a note to add it when
 the authorities have the latest descriptor.

 Updated.

 Replying to [comment:31 teor]:
 > This operator also enabled a DirPort:
 > E8D114B3C78D8E6E7FEB1004650DD632C2143C9E
 > https://lists.torproject.org/pipermail/tor-relays/2019-June/017438.html

 Added.

 > And this operator nominated their relay:
 > 0338F9F55111FE8E3570E7DE117EF3AF999CC1D7
 > https://lists.torproject.org/pipermail/tor-relays/2019-June/017440.html

 Already in the file.

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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28797 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:  #28793 => #28797


Comment:

 We're not going to have time to do this any time 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] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 This is a quick change, because we can just copy these files from tor.
 And do a quick README.

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

Re: [tor-bugs] #28797 [Core Tor/Fallback Scripts]: Set up CI on the fallback script with a small number of relays

[Tor Bug Tracker & Wiki]

#28797: Set up CI on the fallback script with a small number of relays
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:  #28793 =>


Comment:

 I don't think we'll do this any time 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

[tor-bugs] #30969 [Core Tor/Fallback Scripts]: Add timestamp, country, and commit keys to the directory list header and log

[Tor Bug Tracker & Wiki]

#30969: Add timestamp, country, and commit keys to the directory list header and
log
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Minor  |   Keywords:  fallback
Actual Points: |  Parent ID:
   Points:  1  |   Reviewer:
  Sponsor: |
---+--
 At the moment, I'm including them in the filename, which isn't ideal.

 We should copy the spec from sbws for timestamp and country, and maybe
 commit if sbws adds it first.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 This operator also enabled a DirPort:
 E8D114B3C78D8E6E7FEB1004650DD632C2143C9E
 https://lists.torproject.org/pipermail/tor-relays/2019-June/017438.html

 And this operator nominated their relay:
 0338F9F55111FE8E3570E7DE117EF3AF999CC1D7
 https://lists.torproject.org/pipermail/tor-relays/2019-June/017440.html

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

Re: [tor-bugs] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.5
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-

Comment (by teor):

 Replying to [comment:9 catalyst]:
 > Replying to [comment:8 teor]:
 > > Replying to [comment:7 catalyst]:
 > > > Thanks! The new tests look reasonable. I wonder if it's necessary to
 make all those multi-statement macro definitions, instead of helper
 functions (and maybe much smaller macros that call those functions)? I
 think helper function would be a little cleaner. Please let me know what
 you think.
 > >
 > > The problem with helper functions is that failures are attributed to
 the test assertions in the helper function, without any context. So it's
 very hard to tell which test data caused the failure.
 > >
 > > I'm not sure if there is some way of providing context as part of the
 test macros. I suggest that we merge this code as-is, because it's
 functional, adds coverage, and makes sure we won't introduce future bugs.
 Then we can open a ticket for follow-up.
 > I see. I agree we should open a new ticket to follow up, in that case.
 >
 > I think I see that the problem is buried in the `TT_DECLARE()` macro in
 `tinytest_macros.h`. I think it's possible to work around it, but it might
 be nontrivial. (Rough sketch: redefine `TT_DECLARE()` in helper functions
 to read file and line info from function parameters, and make file and
 line numbers explicit parameters to helper functions.)

 I opened #30968 with your suggestion, and my alternate suggestion (a
 format string that allows us to print the data being tested).

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

Re: [tor-bugs] #30968 [Core Tor/Tor]: Refactor unit test asserts so they log context

[Tor Bug Tracker & Wiki]

#30968: Refactor unit test asserts so they log context
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, technical-debt, ipv6,  |  Actual Points:
  tor-dns, sponsor-31-maybe  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  refactor, technical-debt, ipv6, tor-dns => refactor,
 technical-debt, ipv6, tor-dns, sponsor-31-maybe


Comment:

 gaba, I don't know if we want to do this refactor as part of sponsor 31.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30968 [Core Tor/Tor]: Refactor unit test asserts so they log context

[Tor Bug Tracker & Wiki]

#30968: Refactor unit test asserts so they log context
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  refactor, technical-debt, ipv6,
 Severity:  Normal   |  tor-dns
Actual Points:   |  Parent ID:
   Points:  2|   Reviewer:
  Sponsor:   |
-+-
 In #30721, I created some complex macros to preserve line numbers when the
 unit tests fail.

 We could refactor these macros into functions, if the tiny test assertions
 supported context.

 catalyst suggests allowing file and line numbers (and functions?):
 > I think I see that the problem is buried in the `TT_DECLARE()` macro in
 `tinytest_macros.h`. I think it's possible to work around it, but it might
 be nontrivial. (Rough sketch: redefine `TT_DECLARE()` in helper functions
 to read file and line info from function parameters, and make file and
 line numbers explicit parameters to helper functions.)

 I suggest allowing a format string, which could also print the data that
 we're testing. (For the tor_addr_port_lookup() tests, the best context is
 the address string.)

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

Re: [tor-bugs] #30578 [Core Tor/Tor]: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___?

[Tor Bug Tracker & Wiki]

#30578: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-
document, or ___?
-+-
 Reporter:  nickm|  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  circuitpadding, 041-should,  |  Actual Points:
  hopefully-easy, wtf-pad|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 (The reason for fixing the test is that it adds about 200 lines of
 coverage, taking circuitpadding from 92 to 94%).

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

Re: [tor-bugs] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.5
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:8 teor]:
 > Replying to [comment:7 catalyst]:
 > > Thanks! The new tests look reasonable. I wonder if it's necessary to
 make all those multi-statement macro definitions, instead of helper
 functions (and maybe much smaller macros that call those functions)? I
 think helper function would be a little cleaner. Please let me know what
 you think.
 >
 > The problem with helper functions is that failures are attributed to the
 test assertions in the helper function, without any context. So it's very
 hard to tell which test data caused the failure.
 >
 > I'm not sure if there is some way of providing context as part of the
 test macros. I suggest that we merge this code as-is, because it's
 functional, adds coverage, and makes sure we won't introduce future bugs.
 Then we can open a ticket for follow-up.
 I see. I agree we should open a new ticket to follow up, in that case.

 I think I see that the problem is buried in the `TT_DECLARE()` macro in
 `tinytest_macros.h`. I think it's possible to work around it, but it might
 be nontrivial. (Rough sketch: redefine `TT_DECLARE()` in helper functions
 to read file and line info from function parameters, and make file and
 line numbers explicit parameters to helper 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] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.5
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:7 catalyst]:
 > Thanks! The new tests look reasonable. I wonder if it's necessary to
 make all those multi-statement macro definitions, instead of helper
 functions (and maybe much smaller macros that call those functions)? I
 think helper function would be a little cleaner. Please let me know what
 you think.

 The problem with helper functions is that failures are attributed to the
 test assertions in the helper function, without any context. So it's very
 hard to tell which test data caused the failure.

 I'm not sure if there is some way of providing context as part of the test
 macros. I suggest that we merge this code as-is, because it's functional,
 adds coverage, and makes sure we won't introduce future bugs. Then we can
 open a ticket for follow-up.

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression,   |
  nickm-merge|
Parent ID:  #30441   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:4 ahf]:
 > I think this looks good. Only very minor nitpick I could think of is to
 change the type of `emit_ed_sigs` from `int` to `bool`, but I don't think
 that's a blocker.

 Yeah, I wouldn't do that in the bugfix, but I guess I could do that after
 the refactor.

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

Re: [tor-bugs] #30963 [Core Tor/Tor]: Shellcheck tests should exclude src/rust/registry

[Tor Bug Tracker & Wiki]

#30963: Shellcheck tests should exclude src/rust/registry
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 It turns out that we're also checking .git and user-specified build
 directories, I opened #30967 for follow up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30967 [Core Tor/Tor]: Explicitly select the top-level directories that we want to shellcheck

[Tor Bug Tracker & Wiki]

#30967: Explicitly select the top-level directories that we want to shellcheck
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 At the moment, we shellcheck all the directories inside the tor directory,
 even user directories like .git, user-specified build directories, and
 directories that are added during tests.

 This change will conflict with #30963, so it should be based on that
 branch.

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

Re: [tor-bugs] #30578 [Core Tor/Tor]: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___?

[Tor Bug Tracker & Wiki]

#30578: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-
document, or ___?
-+-
 Reporter:  nickm|  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  circuitpadding, 041-should,  |  Actual Points:
  hopefully-easy, wtf-pad|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * reviewer:  mikeperry => asn


Comment:

 Ok, I fixed the test and resolved the flapping issue. Shifting the
 circuitsetup machine by 2ms ensures that the call of
 timers_advaance_and_run(1) from circuit_package_relay_cell_mock() does not
 trigger the circuitsetup relay side machine to send padding (which was the
 problem).

 https://github.com/torproject/tor/pull/1141

 I am going to switch reviewer back to asn for the test flapping fix
 commits. The rest look good to me.

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

Re: [tor-bugs] #30721 [Core Tor/Tor]: tor_addr_port_lookup() is overly permissive

[Tor Bug Tracker & Wiki]

#30721: tor_addr_port_lookup() is overly permissive
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-addr, refactor,  |  Actual Points:  1.5
  practracker-improvement|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by catalyst):

 * status:  needs_review => needs_information


Comment:

 Thanks! The new tests look reasonable. I wonder if it's necessary to make
 all those multi-statement macro definitions, instead of helper functions
 (and maybe much smaller macros that call those functions)? I think helper
 function would be a little cleaner. Please let me know what you think.

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

Re: [tor-bugs] #30716 [Circumvention/Obfs4]: Improve the obfs4 obfuscation protocol

[Tor Bug Tracker & Wiki]

#30716: Improve the obfs4 obfuscation protocol
+--
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  assigned
 Priority:  High|  Milestone:
Component:  Circumvention/Obfs4 |Version:
 Severity:  Normal  | Resolution:
 Keywords:  sponsor28, anti-censorship-roadmap  |  Actual Points:
Parent ID:  | Points:  20
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--
Description changed by phw:

Old description:

> As part of our work for Sponsor 28, we will evaluate and improve the
> obfs4 obfuscation protocol.
>
> Roger started the discussion [https://lists.torproject.org/pipermail
> /anti-censorship-team/2019-May/15.html on our anti-censorship-team
> mailing list]. Relevant reading is the CCS'15 paper
> [https://censorbib.nymity.ch/#Wang2015a Seeing through Network-Protocol
> Obfuscation] and the S'16 paper
> [https://censorbib.nymity.ch/#Tschantz2016a SoK: Towards Grounding
> CensorshipCircumvention in Empiricism].
>
> Let's use this ticket to keep track of this effort.
>
> Suggestions for improvement:
> * [https://trac.torproject.org/projects/tor/ticket/30716#comment:1
> yawning writes] that obfs4 doesn't easily support backward incompatible
> protocol alterations.
> * [https://trac.torproject.org/projects/tor/ticket/30716#comment:3
> yawning writes] that the framing could use better cryptography.
> * [https://trac.torproject.org/projects/tor/ticket/30716#comment:2 dcf
> writes] that during the handshake, the client needs to wait for the
> server before it can send more data. A
> [https://lists.torproject.org/pipermail/tor-dev/2017-June/012310.html
> tor-dev@] post has more detail.
> * Each obfs4 server has a unique flow signature. Can we make packet
> payload unique to each server too? For example, can we automatically
> derive a formal language, so not all obfs4 instances send high-entropy
> data?

New description:

 As part of our work for Sponsor 28, we will evaluate and improve the obfs4
 obfuscation protocol, which may result in obfs5.

 Roger started the discussion [https://lists.torproject.org/pipermail/anti-
 censorship-team/2019-May/15.html on our anti-censorship-team mailing
 list]. Relevant reading is the CCS'15 paper
 [https://censorbib.nymity.ch/#Wang2015a Seeing through Network-Protocol
 Obfuscation] and the S'16 paper
 [https://censorbib.nymity.ch/#Tschantz2016a SoK: Towards Grounding
 CensorshipCircumvention in Empiricism].

 Let's use this ticket to keep track of this effort. Below is a list of
 ideas that we may or may not want to incorporate in obfs5.

 == Randomisation

 Obfs4 already implements randomisation for packet lengths and inter-
 arrival times but there are other protocol aspects that we can randomise.
 Note that the adoption of these strategies may complicate censorship
 analysis: if obfs5 instance X looks very different from obfs5 instance Y,
 then X may end up getting blocked while Y still works. Instead of saying
 "obfs5 is blocked," one may then have to be more specific and say "the
 obfs5 instances that rely on UDP are blocked."

 * **Payload**: All bytes that obfs4 writes to the wire are randomly
 distributed. These high-entropy packets may or may not be common on the
 Internet. We could evade a "high-entropy filter" by having obfs4 servers
 derive a formal language from the shared secret. This language could, say,
 use dummy clear-text headers.

 * **Cover traffic**: [https://lists.torproject.org/pipermail/tor-
 dev/2017-June/012310.html dcf] explains that obfs4 only sends data when
 it's given data to send. To improve on this, as dcf suggests, we could
 make obfs5 send data even when the application has nothing to send.

 * **Packet directions**: An obfs4 flow begins with the client sending data
 to the server. We could randomise packet directions and have, say, the
 server talk first with a server-specific probability.

 * **Transport protocol**: An obfs4 server could talk either TCP or UDP or
 SCTP. This may very well not be worth the effort.

 == Lessons learned from [https://censorbib.nymity.ch/#Wang2015a CCS'15
 paper]

 * DPI boxes tend to classify flows by only inspecting the first N packets
 of a flow. Keeping state is expensive, after all. We could exploit this by
 relaxing our obfuscation techniques after N packets to increase
 throughput.

 * The paper's data set may not be representative of what countries or ISPs
 would see:
   * It's "only" a university uplink. Universities typically have policies
 that prohibit file sharing such as BitTorrent. BitTorrent's "message
 stream encryption" may look similar to 

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alsmith):

 Replying to [comment:2 arma]:


 > Replying to [comment:1 alsmith]:
 >
 > > Another issue I'm noticing: When I download a document (.xlxs and
 .docx so far) from NextCloud, I get a many-days-old version of the
 document instead of what is in the collaborative editing version of the
 document.
 > >
 >
 > Oh hey, I saw an issue with nc.riseup.net that matches this behavior:
 Gaba pointed me to an xlsx hosted there, and the online version worked
 (after spending a few minutes loading), but the downloaded version was
 just a blank xlsx file. I was confused, but maybe it was giving me the
 many-days-old version, i.e. back when it first started.

 Haven't been able to replicate this problem yet, but it seems something
 similar but opposite is happening as well, as reported to be by Bekeela:

 - I sent Bekeela a link to an xlsx doc. I had created this document
 roughly 15 minutes before sending it to her.

 - Half an hour later, Bekeela visited the link and the collaborative
 editing version of the document was blank. She was then served this error
 "The editor version has been updated. The page will be reloaded to apply
 the changes." Nothing happened.

 - She had to download, and once she did, the content was available.

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 > 1. Gray icon for disabled

 Needs #30934

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by arlolra:

Old description:

> In comment:40:ticket:23888 @antonela wrote,
>
> > Some comments:
> > - The icon is a great way to offer visual feedback to users. I remember
> we discussed it a bit at
> https://trac.torproject.org/projects/tor/ticket/27385#comment:8. Using
> the states described at the comment:35, we have:
> > 1. Gray icon for disabled
> > 2. Purple icon for enabled (waiting)
> > 3. Rotating purple icon for proxying (enabled + transferring). I did
> the animation with CSS here ​https://snowfl4k3.glitch.me/.
> > - The doorhanger can be narrower. 320px is fair enough.
> > - Could we use the system font? In that way, it will use the client's
> default. Now, it is loading Times New Roman.
> > - The copy is great. Although, I think we can iterate over the
> technical terms in the future.

New description:

 In comment:40:ticket:23888 @antonela wrote,

 > Some comments:
 > - The icon is a great way to offer visual feedback to users. I remember
 we discussed it a bit at
 https://trac.torproject.org/projects/tor/ticket/27385#comment:8. Using the
 states described at the comment:35:ticket:23888, we have:
 > 1. Gray icon for disabled
 > 2. Purple icon for enabled (waiting)
 > 3. Rotating purple icon for proxying (enabled + transferring). I did the
 animation with CSS here ​https://snowfl4k3.glitch.me/.
 > - The doorhanger can be narrower. 320px is fair enough.
 > - Could we use the system font? In that way, it will use the client's
 default. Now, it is loading Times New Roman.
 > - The copy is great. Although, I think we can iterate over the technical
 terms in the future.

--

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 > The doorhanger can be narrower. 320px is fair enough.

 I see, this rendered differently between browsers.  Fixed in,
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=ff6f91f3dacb02fedfce7fe965e385cbe4965520

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

Re: [tor-bugs] #29211 [Core Tor/Tor]: Distribute config.c functionality across more modules

[Tor Bug Tracker & Wiki]

#29211: Distribute config.c functionality across more modules
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  15
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Here is my current plan for the refactoring.

 '''High-level goals'''

 The end goal is that every module should define, via a hook in the
 subsystem API, which variables it uses.  The config_var_t structure is a
 natural way to note this, since it maps a variable to a struct field, but
 it has some problems:
   * Its implementation is a huge pile of switch statements and special
 cases
   * It combines multiple responsibilities in one blob of code
   * It is difficult to extend
   * It describes a field in a _single_ structure, and is difficult to
 aggregate into our target implementation, wherein every module has its own
 configuration structure.
   * Its current implementation depends on every type in the code that can
 be used as a configuration variable.  Since routerset_t is one such (high
 level) type, and since we may expect other high-level types to exist in
 the future, we need a better way to make this system extensible.

 '''Code dependencies'''

 src/lib/conf will be code that is used by modules that need to define
 configurable items.

 src/lib/confmgt/ will be generic code for manipulating configuration
 variables in objects.  It will handle reading and writing from strings to
 struct members, and finding the appropriate struct members to read and
 write, and so on.  It will only be used by higher level modules that need
 to do data-driven access to configuration.  Configurable modules will just
 need lib/conf and lib/susbsys.

 src/app/config/ will do the work of collecting all the configurable
 objects, reloading the configuration when appropriate, and notifying
 different subsystems when the configuration has changed.

 '''Branches so far'''

 In #30893, I tried to get to 100% test coverage on confparse.c, since
 that's the module that will be most affected by this refactoring.  I
 missed a couple of spots, but those will be fixed as part of the #30864
 branch to avoid conflicts.  This branch is now merged.

 The next branch, #30864, extracts the lowest level of introspection code
 from confparse.c: the code to manipulate typed values via a pointer and a
 type definition.  This functionality is in the typed_var module, and it's
 not meant for direct use: it's a very low level api.

 The next branch, #30914, wraps the typed_var API inside a struct_var API,
 which instead of referring to a pointer to typed data, refers to a typed
 member within a struct.  It extracts this API from confparse.c, and cleans
 it up a lot.  Once again, it makes confparse.c simpler.

 The next branch, #30935, refactors config_var_t a bit, and moves it to
 lib/conf where it belongs.  It is full of miscellaneous refactorings on
 the confparse.c code and its users.  Notably, it removes all code in
 confparse.c or config.c that does "special-case" inspection of a
 variable's type, and it removes the need to update tiny little macro
 definitions all over the code.  It also removes special-case handling of
 "magic" variable names like those that start with __ and ___.  Finally --
 and necessarily for my sanity -- it refactors our horrible old handling of
 TestingTorNetwork.

 '''Next steps'''

 The next major branch here will refactor config_fmt_t so that instead of
 describing a mapping from variable names to a single struct, it describes
 an extensible mapping from variable names to many structs.  There will
 need to be a corresponding "group of structs" object that confparse.c and
 config.c use in place of their current or_options_t manipulation.  That
 will be done in #30866.

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

Re: [tor-bugs] #30864 [Core Tor/Tor]: Move variable manipulation code out of confparse.c

[Tor Bug Tracker & Wiki]

#30864: Move variable manipulation code out of confparse.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  2.5
Parent ID:  #29211| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Squashed and rebased per request.

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

Re: [tor-bugs] #30609 [Applications/Tor Browser]: Issue Starting Tor Browser On Windows

[Tor Bug Tracker & Wiki]

#30609: Issue Starting Tor Browser On Windows
--+---
 Reporter:  broman|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:  tor browser error |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => closed
 * version:  Tor: 0.4.0.5 =>
 * resolution:   => not a bug


Comment:

 That's not Tor crashing but not being able to connect properly. It seems
 someone/something is intefering with the Tor connection and Tor therefore
 fails. You could try using a built-in bridge to work around that, see:
 https://tb-manual.torproject.org/transports/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30966 [Webpages/Website]: Install instructions for Linux/Ubuntu users who might not be entirely familiar with tar.xz

[Tor Bug Tracker & Wiki]

#30966: Install instructions for Linux/Ubuntu users who might not be entirely
familiar with tar.xz
-+--
 Reporter:  torlove  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Webpages/Website
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Its been a few months since I've installed it myself. I know that it needs
 to be extracted somewhere, but I need to remind myself of the location. A
 simple page similar to the page instructing users how to verify the gpg
 signature may be advantageous and improve the new user experience.

 ON THIS PAGE:
 https://tb-manual.torproject.org/

 Between the subsection "Downloading" and "Running Tor for the first time"
 there may be an "Installation" section listed with basic instructions.

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

[tor-bugs] #30965 [Webpages/Website]: Tor Browser is now on F-Droid so remove the "s00n" (soon) from button and make it clickable

[Tor Bug Tracker & Wiki]

#30965: Tor Browser is now on F-Droid so remove the "s00n" (soon) from button 
and
make it clickable
-+--
 Reporter:  torlove  |  Owner:  hiro
 Type:  task | Status:  new
 Priority:  Medium   |  Component:  Webpages/Website
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Fix F-Droid button near the bottom of this page:
 https://www.torproject.org/download/

 Link to https://f-droid.org

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

Re: [tor-bugs] #30957 [Applications/Tor Browser]: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

[Tor Bug Tracker & Wiki]

#30957: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by torlove):

 Thanks for your prompt response, too, btw.

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

Re: [tor-bugs] #30957 [Applications/Tor Browser]: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

[Tor Bug Tracker & Wiki]

#30957: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by torlove):

 Hello gk,

 In my request I'm asking for the option to "Save" on long-press. It's
 relatively common today for people to long-press a link in order to
 download it.

 The side request is asking whether there is a way to change the default
 behaviour for myself only, by editing a config file.

 This problem of mismatching newline characters has happened to me. It is
 an arduous thing to fix on a small device, as one must manually remove the
 new lines and then re-input them in the text editor. Very error prone.
 Thankfully this did not happen on this occasion, however regardless of
 whether that happens or not, the user need to copy and paste the signature
 into a new text file, and then save that file to the correct folder, etc.
 Suboptimal.

 Is there a security reason for ascii (incl. PGP signature) files to not be
 savable? By their very purpose they should be savable/downloadable by
 long-press. Any errors or problems in that process could easily be relayed
 to the user, hence aborting the download.

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

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alsmith):

 Replying to [comment:14 micah]:


 > Replying to [comment:12 alsmith]:
 >
 > > Replying to [comment:11 micah]:
 > >
 > >
 > >
 > > > Replying to [comment:10 micah]:
 > > >
 > > >
 > > > > Replying to [comment:9 alsmith]:
 > > > >
 > > > > > Thanks for your reply!
 > > > > > Replying to [comment:7 micah]:
 > > > > >
 > > > > > > Replying to [ticket:30869 alsmith]:
 > > > > > > Yes, the Onlyoffice functionality is primarily oriented around
 the collaborative elements. Finishing/printing documents are maybe not as
 refined. Perhaps we can investigate how to get the Tor Project fonts
 available, so this could minimize the problems. Which is the font that is
 used? I can look at what it would take to incorporate that.
 > > > > > >
 > > > > > Fair. Finishing features are less important than the
 collaborative functions. Font is Source Pro (Serif & Sans Serif versions),
 more here: https://styleguide.torproject.org/visuals/#typography.
 > > > > >
 > > > > Ok, I'll see what is involved in adding fonts.
 > > > >
 > > > I've added the Source Pro fonts, see if they work for you!
 > > >
 > >
 > > Tysm! Checked right now, I am not seeing the fonts yet.
 > >
 >
 > So there might be two reasons for this:
 >
 > 1. *maybe* they only show up for new documents? I kind of doubt this...
 but for sure they would require that you reload a document from nextcloud.
 >
 > 2. I do know that your browser cache can impact this, once it has been
 cleared (maybe by restarting the browser), they should show
 >
 > I'm definitely seeing them right now with a new document, when I pull
 down the fonts menu and go down to "Source"

 Cache cleared and font now available in new and old docs. Thank you.

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression,   |
  nickm-merge|
Parent ID:  #30441   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged appropriate branches to 0.4.1 and master.

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

Re: [tor-bugs] #30964 [Core Tor/Tor]: Fix shellcheck warning about unused variable in test_rebind.sh

[Tor Bug Tracker & Wiki]

#30964: Fix shellcheck warning about unused variable in test_rebind.sh
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * actualpoints:   => 0


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

Re: [tor-bugs] #30964 [Core Tor/Tor]: Fix shellcheck warning about unused variable in test_rebind.sh

[Tor Bug Tracker & Wiki]

#30964: Fix shellcheck warning about unused variable in test_rebind.sh
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 branch `bug30964` with PR at https://github.com/torproject/tor/pull/1140

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30964 [Core Tor/Tor]: Fix shellcheck warning about unused variable in test_rebind.sh

[Tor Bug Tracker & Wiki]

#30964: Fix shellcheck warning about unused variable in test_rebind.sh
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0 |   Reviewer:
  Sponsor:|
--+
 {{{
 In ./src/test/test_rebind.sh line 15:
 exitcode=0
 ^--^ SC2034: exitcode appears unused. Verify use (or export if used
 externally).
 }}}

 I say "no backport" since this is  harmless.

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

Re: [tor-bugs] #30963 [Core Tor/Tor]: Shellcheck tests should exclude src/rust/registry

[Tor Bug Tracker & Wiki]

#30963: Shellcheck tests should exclude src/rust/registry
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * actualpoints:   => 0


Comment:

 Branch is `bug30963`; PR at https://github.com/torproject/tor/pull/1139 .
 Trivial fix.

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

[tor-bugs] #30963 [Core Tor/Tor]: Shellcheck tests should exclude src/rust/registry

[Tor Bug Tracker & Wiki]

#30963: Shellcheck tests should exclude src/rust/registry
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There are shell scripts that can get downloaded into src/rust/registry,
 but they are not in our control: we should tell shellcheck not to look at
 them.

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

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by micah):

 Replying to [comment:12 alsmith]:
 > Replying to [comment:11 micah]:
 >
 >
 > > Replying to [comment:10 micah]:
 > >
 > > > Replying to [comment:9 alsmith]:
 > > > > Thanks for your reply!
 > > > > Replying to [comment:7 micah]:
 > > > > > Replying to [ticket:30869 alsmith]:
 > > > > > Yes, the Onlyoffice functionality is primarily oriented around
 the collaborative elements. Finishing/printing documents are maybe not as
 refined. Perhaps we can investigate how to get the Tor Project fonts
 available, so this could minimize the problems. Which is the font that is
 used? I can look at what it would take to incorporate that.
 > > > > Fair. Finishing features are less important than the collaborative
 functions. Font is Source Pro (Serif & Sans Serif versions), more here:
 https://styleguide.torproject.org/visuals/#typography.
 > > > Ok, I'll see what is involved in adding fonts.
 > > I've added the Source Pro fonts, see if they work for you!
 >
 > Tysm! Checked right now, I am not seeing the fonts yet.

 So there might be two reasons for this:

 1. *maybe* they only show up for new documents? I kind of doubt this...
 but for sure they would require that you reload a document from nextcloud.

 2. I do know that your browser cache can impact this, once it has been
 cleared (maybe by restarting the browser), they should show

 I'm definitely seeing them right now with a new document, when I pull down
 the fonts menu and go down to "Source"

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

Re: [tor-bugs] #30649 [Core Tor/Tor]: Every few hours, relays [warn] Received circuit padding stop command for unknown machine.

[Tor Bug Tracker & Wiki]

#30649: Every few hours, relays [warn] Received circuit padding stop command for
unknown machine.
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, circuitpadding, wtf-pad,  |  Actual Points:
  041-must   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Asn's changes are fine with me. I'm not the reviewer though, so just
 setting back to needs_review.

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression,   |
  nickm-merge|
Parent ID:  #30441   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * keywords:
 tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe,
 041-regression, dgoulet-merge
 =>
 tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe,
 041-regression, nickm-merge


Comment:

 okay.  now that ahf has reviewed it too, I can merge.  Thanks, everybody!

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

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alsmith):

 Replying to [comment:10 micah]:


 > Replying to [comment:9 alsmith]:
 >
 > > Thanks for your reply!
 > >
 > > Replying to [comment:7 micah]:
 > >
 > >
 > > > Replying to [ticket:30869 alsmith]:
 > > >
 > > >
 > > > > * No ability to tag other accounts in comments that I can see or
 find. In my eyes, this is the biggest roadblock. Being able to work
 asynchronously on a document, tagging others in spots where their input is
 needed, knowing they will receive notifications, has been key to working
 across time zones with lots of people against deadlines.
 > > > >
 > > > >
 > > > This would be a nice feature. The only way I know that you can
 somewhat get this kind of functionality is to agree as a group that
 comments are things that must be resolved and that people should be
 looking through comments for their names to find ones that they need to
 resolve. Once they've resolved them, then the comment can be closed by
 clicking the "Resolve" button if it was solved.
 > > >
 > >
 > > I understand that this isn't possible with OnlyOffice -- just
 elaborating on this point for the record. Coming to a consensus about how
 to resolve and labeled could be possible, although cumbersome. After
 writing or documenting rules for resolving comments, I can see the need
 for me (or other authors) to notify others every time there's a new
 comment -- which is not simple to keep track of in large projects with
 many comments and edits. This will be logistically quite difficult (and
 time-consuming) for those who are authoring or managing a document.
 > >
 > I will look around for an issue related to this upstream, and if there
 is not one, I'll create one so we can track the feature.

 Thank you!

 > > > > * Speed. For me, !OnlyOffice docs take 2-3 minutes to load per
 file. Working on one or two small documents, this is doable. For huge
 projects with multiple long/large documents, this may become
 difficult/impossible to manage.
 > > > >
 > >
 > >
 > > > That is interesting, I haven't experienced that. I just opened a
 document, and it took 5 seconds between clicking on it in nextcloud, and
 it being editable in OnlyOffice. I'm really interested in exploring this
 delay more to figure out what is causing it to take so long for you. Are
 you experiencing this for all document types, or just certain ones... do
 you experience it only with larger documents?
 > > >
 > >
 > > Speed is an issue with all documents, all types, all sizes. I'd say 1
 out of 5 times it's so slow it times out. I use Tor Browser exclusively
 when accessing NextCloud. Maybe that's the issue; I'll test and report
 back.
 > >
 >
 > Ok, yeah... when using tor you are going to have very different
 latencies in play that will make it hard to evaluate if the issue is
 OnlyOffice itself. The server runs out of Seattle, so it should be very
 fast for you to connect to it over the "clearnet". I'd be interested to
 hear your experiences after you've tried it without Tor Browser.

 OK, yes, after using NC through other browser it's significantly faster
 and I'm not getting that time out issue. Hooray!

 > > > > * No ability to do a word/character count that I can find.
 Critical for grants, most have word or character count requirements.
 > > > >
 > > > >
 > > > It is possible to do this, but I think it could be more 'easy'. The
 way you can do this is by clicking the "File" button on the left (Alt+F),
 its a little icon that looks like a document and is above the search
 spyglass. Then click "Document Info..." and you will get the counts you
 are looking for.
 > > >
 > > > This isn't ideal, and the OnlyOffice developers are aware of this
 enhancement request. The idea would be to put it in the status bar at the
 bottom, where it tells you the page number you are on.
 > > >
 > >
 > > Yes -- sorry, I should have been more clear. You can get word and
 character counts for the entire document, but I can't select a paragraph
 and get the word count or character count of that section, which is what I
 use frequently. I've been writing in !OnlyOffice then copy/pasting chunks
 of 

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by alsmith):

 Replying to [comment:11 micah]:


 > Replying to [comment:10 micah]:
 >
 > > Replying to [comment:9 alsmith]:
 > > > Thanks for your reply!
 > > > Replying to [comment:7 micah]:
 > > > > Replying to [ticket:30869 alsmith]:
 > > > > Yes, the Onlyoffice functionality is primarily oriented around the
 collaborative elements. Finishing/printing documents are maybe not as
 refined. Perhaps we can investigate how to get the Tor Project fonts
 available, so this could minimize the problems. Which is the font that is
 used? I can look at what it would take to incorporate that.
 > > > Fair. Finishing features are less important than the collaborative
 functions. Font is Source Pro (Serif & Sans Serif versions), more here:
 https://styleguide.torproject.org/visuals/#typography.
 > > Ok, I'll see what is involved in adding fonts.
 > I've added the Source Pro fonts, see if they work for you!

 Tysm! Checked right now, I am not seeing the fonts yet.

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 > Yes, exactly

 Ok, done in,
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=a70f5b9181c4805ef10e13495c94d7e145435a81

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression,   |
  dgoulet-merge  |
Parent ID:  #30441   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-

Comment (by ahf):

 I think this looks good. Only very minor nitpick I could think of is to
 change the type of `emit_ed_sigs` from `int` to `bool`, but I don't think
 that's a blocker.

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

Re: [tor-bugs] #30953 [Core Tor/Tor]: ServerTransportListenAddr is ignored when stated second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30953: ServerTransportListenAddr is ignored when stated second time for the 
IPv6
address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 > Currently is possible to run a dual stacked IPv4 + IPv6 bridge.

 But not with any pluggable transport, because of the descriptor file and
 PT configuration protocol.  Really the correct fix is to allow a single PT
 instance to be configured for and publish multiple addresses as a vector.

 This was brought up the last time there was talk about revamping the PT
 spec, but the people that did the 2.0 spec didn't care about 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] #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:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201906|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 FWIW, John Haller from PortableApps applied a fix (see
 https://portableapps.com/node/60299 , and comment 9), but I'm not entirely
 sure what he did, but also had an additional issue (see
 https://portableapps.com/node/60496 ) with `addonStartup.json.lz4`.

 Let me know if you would like me to reach out to John Halter and ask what
 he did, but I think you know what needs to be done already, and getting
 this done upstream is the best solution IMO.

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by antonela):

 > is that what you mean?

 Yes, exactly. This should work:

 {{{
 body {
   margin: 1em;
   font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-
 Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;
 }
 }}}


 https://css-tricks.com/snippets/css/system-font-stack/

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

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by micah):

 Replying to [comment:10 micah]:
 > Replying to [comment:9 alsmith]:
 > > Thanks for your reply!
 > >
 > > Replying to [comment:7 micah]:
 > >
 > > > Replying to [ticket:30869 alsmith]:
 > > > Yes, the Onlyoffice functionality is primarily oriented around the
 collaborative elements. Finishing/printing documents are maybe not as
 refined. Perhaps we can investigate how to get the Tor Project fonts
 available, so this could minimize the problems. Which is the font that is
 used? I can look at what it would take to incorporate that.
 > >
 > > Fair. Finishing features are less important than the collaborative
 functions. Font is Source Pro (Serif & Sans Serif versions), more here:
 https://styleguide.torproject.org/visuals/#typography.
 >
 > Ok, I'll see what is involved in adding fonts.

 I've added the Source Pro fonts, see if they work for you!

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

Re: [tor-bugs] #23888 [Circumvention/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
-+-
 Reporter:  oarel|  Owner:  arlolra
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-pt, ex-sponsor-19   |  implemented
  ,anti-censorship-roadmap, snowflake-   |  Actual Points:
  webextension   |
Parent ID:  #30931   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by arlolra):

 > I'm not sure if re-open this ticket or file a new one.

 I opened #30962, let's continue there.

 > Please publish it on Mozilla's AMO, if it's functional please let us
 know so I can start publicizing it.

 Thanks for your interest.  We're still working on getting it published in
 #30931

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

Re: [tor-bugs] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by arlolra):

 * cc: antonela (added)


Comment:

 > Could we use the system font? In that way, it will use the client's
 default. Now, it is loading Times New Roman.

 We haven't defined a font-family yet,
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/webext/popup.css

 Search for "system" returns something like,
 {{{
 font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-
 Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;
 }}}

 Is that what you mean?

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

Re: [tor-bugs] #30024 [Applications/Tor Browser]: Objective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service version

[Tor Bug Tracker & Wiki]

#30024: Objective 2, Activity 3: Notify users if a current website they are
visiting on Tor Browser has an onion service version
--+
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #30281| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by antonela):

 Replying to [comment:5 gk]:
 > What is the functionality of the onion icon here? The circuit display is
 bound to the load of the website. Thus, either it got already loaded over
 alt-svc or not. In either case the circuit display should match what
 actually happened. I don't think we should bind it to whether the user
 clicked on the onion icon or not. And, yes, it is crucial that the URL
 remains as it is in this scenario as it is, as there is not really a
 redirect happening.
 >
 Yes, the circuit display should render exactly what is happening and the
 url bar address will not change. Do we want to have an onion icon at the
 url bar to show that foo.com has been accessed through an onion?


 > Again, what is the functionality of the .onion icon? Does the .onion
 version get loaded once I click on it? If so, then the URL bar domain
 should change and the circuit display. If not then both should stay as the
 display is bound to the actual requests happen(ed).We need to think about
 the opt-in saving here as well and how we expose that, as in #30237.
 >
 The identity and the onion icons are triggering the same behavior: open
 the doorhanger. There is not any actionable behavior at the onion icon but
 opening the doorhnager. At the moment, they don't open different
 doorhangers.

 The onion icon made explicit that the traffic is going through an onion
 service, even in the cases where the domain name is not a .onion but this
 is happening under the hood. That is the main idea behind the onion icon.
 Ideally, we can rely on this icon as the next iteration of the different
 security feedback we achieved following up #23247. This is relevant for
 Tor Browser because we want to be an educational resource for people to
 understand when an onion service is being used. For 3rd parties
 implementing Tor, the onion icon becomes relevant to brand the Tor
 traffic.


 > How would you verify a truncated version of the onion address? And what
 would you use the copy for?
 >
 How are users verifying onion addresses integrity nowadays? That is
 interesting research to run.


 > I am not sure what that means? Which of the 3 scenarios above do you
 have in mind here? And how does that work with Tor Browser not saving
 state to disk?
 >
 As far as I understand, the only scenario that allows us to recommend
 onions at this moment is alt-onions. Other scenarios may allow us to have
 an onion icon at the URL bar (when the client knows that an onion service
 has been used) but cannot trigger that recommendation upfront before user
 opt-in. That is the main use case for alt-onions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30962 [Circumvention/Snowflake]: Improve the webextension design

[Tor Bug Tracker & Wiki]

#30962: Improve the webextension design
-+-
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:  snowflake-
 |  webextension
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In comment:40:ticket:23888 @antonela wrote,

 > Some comments:
 > - The icon is a great way to offer visual feedback to users. I remember
 we discussed it a bit at
 https://trac.torproject.org/projects/tor/ticket/27385#comment:8. Using the
 states described at the comment:35, we have:
 > 1. Gray icon for disabled
 > 2. Purple icon for enabled (waiting)
 > 3. Rotating purple icon for proxying (enabled + transferring). I did the
 animation with CSS here ​https://snowfl4k3.glitch.me/.
 > - The doorhanger can be narrower. 320px is fair enough.
 > - Could we use the system font? In that way, it will use the client's
 default. Now, it is loading Times New Roman.
 > - The copy is great. Although, I think we can iterate over the technical
 terms in the future.

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

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  If I remember correctly, we can't move tickets between projects in
 gitlab. I've added it to the list as something to check.

 I think that was solved recently:

 https://about.gitlab.com/2016/04/20/feature-highlight-move-issues/

 >  I checked the GitLab integrations, Jenkins works, but Travis and
 Appveyor don't. So we need to keep mirroring git to GitHub for Travis and
 Appveyor.

 Yeah, I don't know if we're talkinga bout getting rid of GitHub here yet.
 One thing at a time. GitLab CI, however, might allow us to replace Travis
 eventually...

 >  I also wonder how many GitLab CI runner machines we will have, and who
 will pay for them.

 ... however this is also out of scope for now. We're talking abuot
 (possibly) replacing Trac, not Trac '''and''' Jenkins all at once. One
 thing at a time. :)

 (That said, if we do eventually replace jenkins with Gitlab CI, the
 builders we have now can just be repurposed for GitLab CI. It's all
 hardware in the end.)

 So, TL;DR: no runers yet, as far as I know, but if people want to
 provision external ones, the sweet thing is this can be done without
 intervention from TPA or GitLab admins...

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression,   |
  dgoulet-merge  |
Parent ID:  #30441   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready
 * reviewer:   => nickm
 * keywords:
 tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe,
 041-regression
 =>
 tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe,
 041-regression, dgoulet-merge


Comment:

 This LGTM; I would like to get it into 0.4.1.3-alpha.

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

Re: [tor-bugs] #30869 [Internal Services/Service - nextcloud]: [Nextcloud] Feedback re: collaborative document editing

[Tor Bug Tracker & Wiki]

#30869: [Nextcloud] Feedback re: collaborative document editing
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:  nextcloud, migration |  Actual Points:
Parent ID:  #29415   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by micah):

 Replying to [comment:9 alsmith]:
 > Thanks for your reply!
 >
 > Replying to [comment:7 micah]:
 >
 > > Replying to [ticket:30869 alsmith]:
 > >
 > > > * No ability to tag other accounts in comments that I can see or
 find. In my eyes, this is the biggest roadblock. Being able to work
 asynchronously on a document, tagging others in spots where their input is
 needed, knowing they will receive notifications, has been key to working
 across time zones with lots of people against deadlines.
 > > >
 > > This would be a nice feature. The only way I know that you can
 somewhat get this kind of functionality is to agree as a group that
 comments are things that must be resolved and that people should be
 looking through comments for their names to find ones that they need to
 resolve. Once they've resolved them, then the comment can be closed by
 clicking the "Resolve" button if it was solved.
 >
 > I understand that this isn't possible with OnlyOffice -- just
 elaborating on this point for the record. Coming to a consensus about how
 to resolve and labeled could be possible, although cumbersome. After
 writing or documenting rules for resolving comments, I can see the need
 for me (or other authors) to notify others every time there's a new
 comment -- which is not simple to keep track of in large projects with
 many comments and edits. This will be logistically quite difficult (and
 time-consuming) for those who are authoring or managing a document.

 I will look around for an issue related to this upstream, and if there is
 not one, I'll create one so we can track the feature.

 > > > * Speed. For me, !OnlyOffice docs take 2-3 minutes to load per file.
 Working on one or two small documents, this is doable. For huge projects
 with multiple long/large documents, this may become difficult/impossible
 to manage.
 >
 > > That is interesting, I haven't experienced that. I just opened a
 document, and it took 5 seconds between clicking on it in nextcloud, and
 it being editable in OnlyOffice. I'm really interested in exploring this
 delay more to figure out what is causing it to take so long for you. Are
 you experiencing this for all document types, or just certain ones... do
 you experience it only with larger documents?
 >
 > Speed is an issue with all documents, all types, all sizes. I'd say 1
 out of 5 times it's so slow it times out. I use Tor Browser exclusively
 when accessing NextCloud. Maybe that's the issue; I'll test and report
 back.

 Ok, yeah... when using tor you are going to have very different latencies
 in play that will make it hard to evaluate if the issue is OnlyOffice
 itself. The server runs out of Seattle, so it should be very fast for you
 to connect to it over the "clearnet". I'd be interested to hear your
 experiences after you've tried it without Tor Browser.

 > > > * To finalize documents for printing or saving to PDF, I need to
 download and then edit again in Word because certain features are not
 available, the biggest being that the Tor Project’s fonts are not
 supported/available.
 > > >
 > > >
 > > Yes, the Onlyoffice functionality is primarily oriented around the
 collaborative elements. Finishing/printing documents are maybe not as
 refined. Perhaps we can investigate how to get the Tor Project fonts
 available, so this could minimize the problems. Which is the font that is
 used? I can look at what it would take to incorporate that.
 >
 > Fair. Finishing features are less important than the collaborative
 functions. Font is Source Pro (Serif & Sans Serif versions), more here:
 https://styleguide.torproject.org/visuals/#typography.

 Ok, I'll see what is involved in adding fonts.

 > > > * No ability to do a word/character count that I can find. Critical
 for grants, most have word or character count requirements.
 > > >
 > > It is possible to do this, but I think it could be more 'easy'. The
 way you can do this is by clicking the "File" button on the left (Alt+F),
 its a little icon that looks like a document and is above the search
 spyglass. Then click "Document Info..." and you will get 

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Oh, wait! You say you don't see any of these issues on Linux. That's
 another WTF :)

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

Re: [tor-bugs] #30577 [Applications/Tor Browser]: Add Fundraising Banner with next TBB security update

[Tor Bug Tracker & Wiki]

#30577: Add Fundraising Banner with next TBB security update
---+---
 Reporter:  pili   |  Owner:  tbb-team
 Type:  task   | Status:
   |  needs_information
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201906  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * Attachment "icon_monthly_donors.zip" added.


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

Re: [tor-bugs] #30960 [Applications/Tor Browser]: Use Incognito mode for keyboard on Android

[Tor Bug Tracker & Wiki]

#30960: Use Incognito mode for keyboard on Android
--+--
 Reporter:  filips123 |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 No worries.

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

Re: [tor-bugs] #30958 [Core Tor/Tor]: Stop removing the ed25519 signature when the extra-info file is too big

[Tor Bug Tracker & Wiki]

#30958: Stop removing the ed25519 signature when the extra-info file is too big
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 029-backport-|  Actual Points:  0.2
  maybe, 035-backport-maybe, 040-backport-   |
  maybe, 041-backport|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Hmm, practracker doesn't like the master branch, but if I fix it, there
 will be conflicts.

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe, 041-regression|
Parent ID:  #30441   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe
 =>
 tor-bridge, tor-pt, 041-backport, regression, sponsor31-maybe,
 041-regression


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

Re: [tor-bugs] #30953 [Core Tor/Tor]: ServerTransportListenAddr is ignored when stated second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30953: ServerTransportListenAddr is ignored when stated second time for the 
IPv6
address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:2 ahf]:
 > Without having looked at specifications or implementation yet, it sounds
 like something we should fix, yeah.

 One to fix this is to run two instances of the PT on different addresses.
 But I don't think the extra-info format allows that. And it doesn't allow
 multiple IP addresses, either:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1211

 So we either need to:
 1. use a different transportname, like obfs4-ipv6
 2. allow IPv4 and IPv6 lines with the same transportname
 3. add an "ipv6=" arg to the arglist

 Option 3 is more like what we do for authorities and fallbacks. And it
 avoids issues with having two lines for the same bridge, which has caused
 subtle bugs in the past.

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

Re: [tor-bugs] #30960 [Applications/Tor Browser]: Use Incognito mode for keyboard on Android

[Tor Bug Tracker & Wiki]

#30960: Use Incognito mode for keyboard on Android
--+--
 Reporter:  filips123 |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by filips123):

 It looks like this was fixed in the new Tor Browser version. The new
 version now only allows private browsing which enables Incognito mode for
 keyboards.

 Sorry for the false bug!

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

Re: [tor-bugs] #30961 [Core Tor/Tor]: Test

[Tor Bug Tracker & Wiki]

#30961: Test
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * component:  - Select a component => Core Tor/Tor


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

[tor-bugs] #30961 [- Select a component]: Test

[Tor Bug Tracker & Wiki]

#30961: Test
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #30960 [Applications/Tor Browser]: Use Incognito mode for keyboard on Android

[Tor Bug Tracker & Wiki]

#30960: Use Incognito mode for keyboard on Android
+--
 Reporter:  filips123   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 On Android (and maybe also iOS), many keyboard apps (including GBoard and
 SwiftKey) include "Incognito mode". When it is enabled, keyboard app don't
 (or at least shouldn't) track and remember entered words.

 This is already used when using "private private" (which comes from
 Firefox). It should also be used on "normal" browsing mode.

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

Re: [tor-bugs] #30953 [Core Tor/Tor]: ServerTransportListenAddr is ignored when stated second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30953: ServerTransportListenAddr is ignored when stated second time for the 
IPv6
address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ahf):

 Without having looked at specifications or implementation yet, it sounds
 like something we should fix, yeah.

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

Re: [tor-bugs] #30953 [Core Tor/Tor]: ServerTransportListenAddr is ignored when stated second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30953: ServerTransportListenAddr is ignored when stated second time for the 
IPv6
address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-pt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * cc: ahf, cohosh (added)
 * keywords:  ipv6 => ipv6, tor-pt
 * version:  Tor: 0.4.1.2-alpha => Tor: unspecified
 * type:  defect => enhancement
 * milestone:   => Tor: unspecified


Comment:

 ahf, cohosh: Is this something you'd like to work on as part of our
 pluggable transport changes?

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

Re: [tor-bugs] #30954 [Core Tor/Tor]: Address torrc option is ignored if set second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30954: Address torrc option is ignored if set second time for the IPv6 address
--+--
 Reporter:  s7r   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #24403| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * version:  Tor: 0.4.1.2-alpha => Tor: unspecified
 * type:  defect => enhancement
 * parent:   => #24403
 * milestone:   => Tor: unspecified


Comment:

 Address behaves as documented in the man page, so this is a feature
 request.

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

Re: [tor-bugs] #30717 [Internal Services]: Consider exempting Matrix.org users from OFTC registered nick requirement

[Tor Bug Tracker & Wiki]

#30717: Consider exempting Matrix.org users from OFTC registered nick 
requirement
---+
 Reporter:  JeremyRand |  Owner:  alison
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * component:  - Select a component => Internal Services


Comment:

 I'm really not sure which component this belongs in.

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

Re: [tor-bugs] #30636 [Metrics/Analysis]: Something funky is going in Iran: numbers of relay users flies off to 1M+

[Tor Bug Tracker & Wiki]

#30636: Something funky is going in Iran: numbers of relay users flies off to 
1M+
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ir|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by xhdix):

 Many users report that they can no longer be directly connected to Tor.
 Connections with Bridge also have problems for them. (Connected but not
 stable)

 There is a problem with handshake in SSL / TLS communication that the time
 of occurrence of the problem is different in each city and ISP.

 logs:
 https://paste.ubuntu.com/p/jrNQGhqBTx/

 [[Image(https://i.imgur.com/XbyPkPLl.jpg,100%)]]

 [[Image(https://i.imgur.com/G9kZEPtl.jpg,100%)]]

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

Re: [tor-bugs] #30019 [Webpages/Website]: Write content for the onion services section in the community portal

[Tor Bug Tracker & Wiki]

#30019: Write content for the onion services section in the community portal
--+
 Reporter:  asn   |  Owner:  asn
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #14389| Points:  3
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

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


Comment:

 This is now done

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #27908, #29004, #29005, #29019

[Tor Bug Tracker & Wiki]

Batch modification to #27908, #29004, #29005, #29019 by irl:


--
Tickets URL: 

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

Re: [tor-bugs] #30959 [Core Tor/Tor]: Add comments about the chunk format in extrainfo_dump_to_string()

[Tor Bug Tracker & Wiki]

#30959: Add comments about the chunk format in extrainfo_dump_to_string()
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-bridge, tor-pt  |  Actual Points:  0.1
Parent ID:  #30958  | Points:  0.1
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Whoever reviews this PR should also review #30958.

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

Re: [tor-bugs] #30958 [Core Tor/Tor]: Stop removing the ed25519 signature when the extra-info file is too big

[Tor Bug Tracker & Wiki]

#30958: Stop removing the ed25519 signature when the extra-info file is too big
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 029-backport-|  Actual Points:  0.2
  maybe, 035-backport-maybe, 040-backport-   |
  maybe, 041-backport|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Whoever reviews this PR should also review #30959.

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

Re: [tor-bugs] #30959 [Core Tor/Tor]: Add comments about the chunk format in extrainfo_dump_to_string()

[Tor Bug Tracker & Wiki]

#30959: Add comments about the chunk format in extrainfo_dump_to_string()
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-bridge, tor-pt  |  Actual Points:  0.1
Parent ID:  #30958  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 See my pull request, which is based on #30956 to avoid conflicts:
 * master: https://github.com/torproject/tor/pull/1137

 It doesn't contain any of the #30958 code.

 Here's a clean merge of #30956 and #30958, just so we can check
 practracker and conflicts:
 * master: https://github.com/torproject/tor/pull/1138

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30959 [Core Tor/Tor]: Add comments about the chunk format in extrainfo_dump_to_string()

[Tor Bug Tracker & Wiki]

#30959: Add comments about the chunk format in extrainfo_dump_to_string()
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  tor-bridge, tor-pt
Actual Points:  0.1   |  Parent ID:  #30958
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 I want to add some extra comments about #30958, after we merge #30956.

 So I opened this ticket for the pull request and merge.

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

Re: [tor-bugs] #30958 [Core Tor/Tor]: Stop removing the ed25519 signature when the extra-info file is too big (was: Add extra-info chunks as whole lines)

[Tor Bug Tracker & Wiki]

#30958: Stop removing the ed25519 signature when the extra-info file is too big
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 029-backport-|  Actual Points:  0.2
  maybe, 035-backport-maybe, 040-backport-   |
  maybe, 041-backport|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * parent:  #30956 =>
 * cc: nickm (added)
 * actualpoints:  0.1 => 0.2
 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.2.x-final
 * keywords:  tor-bridge, tor-pt =>
 tor-bridge, tor-pt, 029-backport-maybe, 035-backport-maybe, 040
 -backport-maybe, 041-backport


Old description:

> In #30956, I discovered one extra-info line that is split across two
> chunks.
>
> If the extra-info file gets too big, tor removes one chunk at a time. So
> each chunk needs to be a complete line.

New description:

 In #30956, I discovered that the ed25519 signature extra-info line is
 split across two chunks.

 If the extra-info file gets too big, tor removes one chunk at a time. So
 each chunk needs to be a complete line.

 Edit: but in this case, we should just stop removing the signature

--

Comment:

 It turns out that we need to split these chunks, because the ed25519
 signature keyword is in the signed part of the document. So I made sure we
 don't remove any signature chunks.

 Nick, do you think we should backport this fix any further than 0.4.1?

 Please see my pull requests:
 * 0.2.9: https://github.com/torproject/tor/pull/1132

 Clean merges:
 * 0.3.5: https://github.com/torproject/tor/pull/1133
 * 0.4.0: https://github.com/torproject/tor/pull/1134
 * 0.4.1: https://github.com/torproject/tor/pull/1135
 * master: https://github.com/torproject/tor/pull/1136

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

Re: [tor-bugs] #24579 [Applications/Tor Browser]: Download- and Play-button are not visible on https://songs.pk

[Tor Bug Tracker & Wiki]

#24579: Download- and Play-button are not visible on https://songs.pk
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:9 gk]:
 > Replying to [comment:8 cypherpunks]:
 > > Yep. Even on Safest. But CTP is still broken.
 >
 > Not sure what CTP is
 Click-to-play.
 > but in case we don't have a bug for that on file could you file one with
 steps to reproduce?
 That site has weird linking of media. Not sure it could ever be fixed at
 all.

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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by clash):

 Replying to [comment:5 gk]:
 > Replying to [comment:4 clash]:
 > > Replying to [comment:3 gk]:
 > > > clash: Does this work in a vanilla Firefox ESR 60 for you? (bundles
 can be found at: https://www.mozilla.org/en-US/firefox/organizations/all/)
 > >
 > >
 > > I just checked, it doesn't.
 >
 > What about a recent Firefox (not one from the ESR train)?  Maybe that's
 already fixed there?

 Before updating to the ESR I tried it on the standard release (67.0.4
 iirc). It didn't work there either.

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

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:7 gk]:
 > Replying to [comment:6 cypherpunks]:
 > > Replying to [comment:5 gk]:
 > > > Replying to [comment:4 cypherpunks]:
 > > > > Replying to [comment:3 gk]:
 > > > > > Works for me, as I said, both in Safer and Safest mode. If you
 still see this problem, please reopen the ticket with your OS,
 > > > > Windows
 > > > > > security settings,
 > > > > Safer
 > > > > > additional browser modifications.
 > > > > Unmodified both stable and alpha.
 > > > > > Please, attach a screenshot as well showing the notification bar
 about the slowdown.
 > > > > Standard yellow bar, nothing special.
 > > > >
 > > > > Overloads one core, loading aframe.io...
 > > >
 > > > Do you get the yellow bar as well in standard mode?
 > > No. But it still happily fucks the system when the page is visible.
 (Not 100% CPU, more load on 32-bit version.)
 > > > If not, which of the prefs we set is causing the problem? (The ones
 in question are: "javascript.options.ion",
 "javascript.options.baselinejit", "javascript.options.native_regexp",
 "media.webaudio.enabled", "mathml.disabled", and
 "gfx.font_rendering.opentype_svg.enabled".
 > > It could be only additional load by processing scripts from
 aframe.io...
 > > "media.webaudio.enabled" - seriously?
 >
 > Yes, that's part of the prefs we currently set (see: #21601).
 But it does nothing. How could it be a problem?
 > But that said it would be still helpful if you could tell us which pref
 is causing the problem (be it by additional load or missing
 optimizations).
 On Safer it sucks for about 5 min. On Standard, if you disable
 "javascript.options.ion", it sucks for about 30 sec. Further disabling
 "javascript.options.baselinejit" will give you the same result as on
 Safer. No surprise. But WTF with Standard?

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

Re: [tor-bugs] #30956 [Core Tor/Tor]: Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are off

[Tor Bug Tracker & Wiki]

#30956: Publish bridge ServerTransportPlugin lines, even when 
ExtraInfoStatistics
are off
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-pt, 041-backport,|  Actual Points:  0.4
  regression, sponsor31-maybe|
Parent ID:  #30441   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * cc: gaba (added)
 * keywords:  tor-bridge, tor-pt => tor-bridge, tor-pt, 041-backport,
 regression, sponsor31-maybe
 * actualpoints:  0.2 => 0.4


Comment:

 Gaba, this ticket can go in sponsor 31 for the refactoring, or a pluggable
 transport sponsor for the bugfix.

 See my pull request:
 * 0.4.1: https://github.com/torproject/tor/pull/1130

 I put the pluggable transport lines straight after the header. This
 conforms to the spec, because the lines can be in any order. And it makes
 the code simpler. It also makes the pluggable transport lines less likely
 to be removed if the extra info descriptor is too big (50 KB, so that's
 unlikely).

 I also did a quick refactor to satisfy practracker on master:
 * master: https://github.com/torproject/tor/pull/1131

 This makes the file bigger, but all the functions are under 100 lines.

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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:4 clash]:
 > Replying to [comment:3 gk]:
 > > clash: Does this work in a vanilla Firefox ESR 60 for you? (bundles
 can be found at: https://www.mozilla.org/en-US/firefox/organizations/all/)
 >
 >
 > I just checked, it doesn't.

 What about a recent Firefox (not one from the ESR train)?  Maybe that's
 already fixed 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] #30957 [Applications/Tor Browser]: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

[Tor Bug Tracker & Wiki]

#30957: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * keywords:   => tbb-mobile
 * component:  - Select a component => Applications/Tor Browser
 * owner:  (none) => tbb-team


Comment:

 I am not convinced we should change the default behavior for text files.
 Where did you copy the contents of the .asc file to? Does this happen if
 you copy the contents from a clean vanilla Fennec as well? Maybe that's a
 general bug Mozilla fixed meanwhile?

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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by clash):

 Replying to [comment:3 gk]:
 > clash: Does this work in a vanilla Firefox ESR 60 for you? (bundles can
 be found at: https://www.mozilla.org/en-US/firefox/organizations/all/)


 I just checked, it doesn't.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30958 [Core Tor/Tor]: Add extra-info chunks as whole lines

[Tor Bug Tracker & Wiki]

#30958: Add extra-info chunks as whole lines
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal|   Keywords:  tor-bridge, tor-pt
Actual Points:  0.1   |  Parent ID:  #30956
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 In #30956, I discovered one extra-info line that is split across two
 chunks.

 If the extra-info file gets too big, tor removes one chunk at a time. So
 each chunk needs to be a complete line.

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

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:6 cypherpunks]:
 > Replying to [comment:5 gk]:
 > > Replying to [comment:4 cypherpunks]:
 > > > Replying to [comment:3 gk]:
 > > > > Works for me, as I said, both in Safer and Safest mode. If you
 still see this problem, please reopen the ticket with your OS,
 > > > Windows
 > > > > security settings,
 > > > Safer
 > > > > additional browser modifications.
 > > > Unmodified both stable and alpha.
 > > > > Please, attach a screenshot as well showing the notification bar
 about the slowdown.
 > > > Standard yellow bar, nothing special.
 > > >
 > > > Overloads one core, loading aframe.io...
 > >
 > > Do you get the yellow bar as well in standard mode?
 > No. But it still happily fucks the system when the page is visible. (Not
 100% CPU, more load on 32-bit version.)
 > > If not, which of the prefs we set is causing the problem? (The ones in
 question are: "javascript.options.ion", "javascript.options.baselinejit",
 "javascript.options.native_regexp", "media.webaudio.enabled",
 "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".
 > It could be only additional load by processing scripts from aframe.io...
 > "media.webaudio.enabled" - seriously?

 Yes, that's part of the prefs we currently set (see: #21601). But that
 said it would be still helpful if you could tell us which pref is causing
 the problem (be it by additional load of missing optimizations).

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

Re: [tor-bugs] #24579 [Applications/Tor Browser]: Download- and Play-button are not visible on https://songs.pk

[Tor Bug Tracker & Wiki]

#24579: Download- and Play-button are not visible on https://songs.pk
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:8 cypherpunks]:
 > Yep. Even on Safest. But CTP is still broken.

 Not sure what CTP is but in case we don't have a bug for that on file
 could you file one with steps to reproduce?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30957 [- Select a component]: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

[Tor Bug Tracker & Wiki]

#30957: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)
-+--
 Reporter:  torlove  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Using Tor browser for Android, one cannot download a '.asc' file by long-
 pressing  it. The signature instead loads in a browser window. No helpful.

 This might be the behaviour for Firefox but I expect better from Tor
 Browser frankly. In my experience copying ascii pgp from the browser
 introduces newline characters that break the signature.

 Is there a temporary workaround for this in a config file? I would prefer
 the default behaviour for this text file to be "Save" but Save is not even
 an option.

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

Re: [tor-bugs] #30605 [Applications/Tor Browser]: accept-language header leaks browser localization

[Tor Bug Tracker & Wiki]

#30605: accept-language header leaks browser localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-parity, user-|  Actual Points:
  feedback, blog |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * priority:  Medium => High
 * cc: dujaus (added)


Comment:

 #30925 is a duplicate.

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

Re: [tor-bugs] #30925 [Applications]: Tor Browser for Android should not leak device language

[Tor Bug Tracker & Wiki]

#30925: Tor Browser for Android should not leak device language
--+---
 Reporter:  dujaus|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => closed
 * version:  Android (Orbot): 1.0.0 =>
 * resolution:   => duplicate


Comment:

 Yes, agreed. We track this in #30605.

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

Re: [tor-bugs] #24579 [Applications/Tor Browser]: Download- and Play-button are not visible on https://songs.pk

[Tor Bug Tracker & Wiki]

#24579: Download- and Play-button are not visible on https://songs.pk
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Yep. Even on Safest. But CTP is still broken.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Great that you closed it as `user disappeared`, meaning that you couldn't
 fix it. But it's a weird reason to close confirmed bugs anyway.
 What the steps do you need when you have the source code? Memory limit
 means that you get the error with your patch, opening no more than 4 media
 instances on a 1 GB VM. The error instead of no cache, because
 > I also have no idea what cypherpunks meant by that comment. The original
 Mozilla code also returns nullptr on **failure**, so we're not changing
 any logic in that regard. It's even documented in the function comment:
 ​https://hg.mozilla.org/releases/mozilla-
 
esr60/file/256453759958ed9c2eb17a0764d2fcfd7f8e3323/dom/media/MediaCache.cpp#l152
 nullptr if **initialization** failed

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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+---
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 clash: Does this work in a vanilla Firefox ESR 60 for you? (bundles can be
 found at: https://www.mozilla.org/en-US/firefox/organizations/all/)

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

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:5 gk]:
 > Replying to [comment:4 cypherpunks]:
 > > Replying to [comment:3 gk]:
 > > > Works for me, as I said, both in Safer and Safest mode. If you still
 see this problem, please reopen the ticket with your OS,
 > > Windows
 > > > security settings,
 > > Safer
 > > > additional browser modifications.
 > > Unmodified both stable and alpha.
 > > > Please, attach a screenshot as well showing the notification bar
 about the slowdown.
 > > Standard yellow bar, nothing special.
 > >
 > > Overloads one core, loading aframe.io...
 >
 > Do you get the yellow bar as well in standard mode?
 No. But it still happily fucks the system when the page is visible. (Not
 100% CPU, more load on 32-bit version.)
 > If not, which of the prefs we set is causing the problem? (The ones in
 question are: "javascript.options.ion", "javascript.options.baselinejit",
 "javascript.options.native_regexp", "media.webaudio.enabled",
 "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".
 It could be only additional load by processing scripts from aframe.io...
 "media.webaudio.enabled" - seriously?

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

Re: [tor-bugs] #30927 [Applications/Tor Browser]: Tor Browser on Windows does not respond to play/pause buttons while playing media.

[Tor Bug Tracker & Wiki]

#30927: Tor Browser on Windows does not respond to play/pause buttons while 
playing
media.
--+--
 Reporter:  clash |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability


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

Re: [tor-bugs] #30441 [Circumvention/BridgeDB]: Stop BridgeDB from handing out offline bridges

[Tor Bug Tracker & Wiki]

#30441: Stop BridgeDB from handing out offline bridges
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Major| Resolution:
 Keywords:  user-feedback, blog, anti-   |  Actual Points:
  censorship-roadmap |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:14 phw]:
 > Replying to [comment:13 teor]:
 > > Replying to [comment:10 phw]:
 > > > I believe one problem is that Serge's cached-extrainfo and cached-
 extrainfo.new do not contain ''all'' bridges that are in networkstatus-
 bridges, so the results only represent a lower bound of unreachable obfs4
 bridges.
 > >
 > > In tor, extrainfo descriptors are only created when statistics are on.
 > > But we could change that so we create extrainfo descriptors that just
 contain the PT lines, even when statistics are off.
 > [[br]]
 > Does this mean that when a, say, obfs4 bridge turns off its statistics,
 we wouldn't know that it runs obfs4 because we never received the
 transport line in its extrainfo document?

 Yes, we made this change in #29018 in 0.4.1.1-alpha, so it's quite a
 recent change.

 In 0.4.0 and earlier, ServerTransportPlugin lines and bridge statistics
 were unconditionally published in extrainfo documents.

 > If so, this seems worth fixing.
 >
 > Also, what config option controls these statistics?

 ExtraInfoStatistics. Some statistics also have their own options.

 I created #30956 for this issue.

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