Re: [tor-bugs] #30372 [Applications/Tor Browser]: Backport Letterboxing

[Tor Bug Tracker & Wiki]

#30372: Backport Letterboxing
-+-
 Reporter:  tom  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  TorBrowserTeam201905   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:   => tbb-fingerprinting-resolution, TorBrowserTeam201905


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

Re: [tor-bugs] #27311 [Community/Tor Support]: Tor wont open. It says...Toe unexpectantly exited.

[Tor Bug Tracker & Wiki]

#27311: Tor wont open. It says...Toe unexpectantly exited.
---+--
 Reporter:  antoine2u  |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  user disappeared
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by phoul):

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


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

Re: [tor-bugs] #27639 [Community/Tor Support]: Tor unexpectedly exited

[Tor Bug Tracker & Wiki]

#27639: Tor unexpectedly exited
---+--
 Reporter:  dr2782 |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  user disappeared
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by phoul):

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


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

Re: [tor-bugs] #27134 [Community/Tor Support]: connect issue

[Tor Bug Tracker & Wiki]

#27134: connect issue
---+--
 Reporter:  ElecLib|  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:  Tor: unspecified
 Severity:  Normal | Resolution:  user disappeared
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by phoul):

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


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

Re: [tor-bugs] #26791 [Community/Tor Support]: Philippines

[Tor Bug Tracker & Wiki]

#26791: Philippines
---+--
 Reporter:  billygoat101   |  Owner:  phoul
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Community/Tor Support  |Version:  Tor: unspecified
 Severity:  Normal | Resolution:  user disappeared
 Keywords:  tor version 7.5.6  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by phoul):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30373 [Core Tor/sbws]: Most headers non-compliant with spec

[Tor Bug Tracker & Wiki]

#30373: Most headers non-compliant with spec
---+
 Reporter:  irl|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 `Keyword` is imported from dir-spec and

 {{{
 KeyValue ::= Keyword "=" Value
 Keyword = KeywordChar+
 KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
 }}}

 but... most headers have underscores in them.

 My parser wasn't strict enough to catch this the first time. ):

 I suggest this is fixed with a specification update to reflect reality
 rather than creating complexity we have to maintain forever parsing two
 sets of keys.

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

Re: [tor-bugs] #30369 [Metrics/Library]: Fix regular expression in descriptor parser to correctly recognize bandwidth files

[Tor Bug Tracker & Wiki]

#30369: Fix regular expression in descriptor parser to correctly recognize
bandwidth files
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me.

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

[tor-bugs] #30372 [Applications/Tor Browser]: Backport Letterboxing

[Tor Bug Tracker & Wiki]

#30372: Backport Letterboxing
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Here's the set of patches, in order, for the esr60 backport:

 https://hg.mozilla.org/try/rev/744a475c948ee8c987d43a6348deca5e9a4a5a61
 https://hg.mozilla.org/try/rev/feeb219584667f53e2c6cd2ddcfcaa89fb6ee243
 https://hg.mozilla.org/try/rev/a550c321f24c823efcb2e8033e6c802f9cd6e44b
 https://hg.mozilla.org/try/rev/a5d945dd5b7070c810b93eddd0232d646b73fc2d
 https://hg.mozilla.org/try/rev/b58bfc0bdc2451715ec895fbd06f40061fa301f9
 https://hg.mozilla.org/try/rev/1b23145ed904be055bf0efe1000e03ec50c02cb3
 https://hg.mozilla.org/try/rev/0b1eef9eeb06668fc06b3b4d877daaf957c3c1da

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 >  all, see

 Gotcha. And why do you feel strongly we should change this?

 > don't put stuff in init

 Do you have a use case where this causes any problems? Putting code in
 init is common, and done by lots of projects.

 > flexibility... and yes, it's worth it

 Sorry, but this isn't terribly persuasive. Personally I think our present
 tests provide both great coverage and readable output but if you have a
 practical reason to think pytest would be better I'm all ears.

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by 0xrichard):

 > Which of these do you strongly feel we should change and why?

 all, see:

 inore = E501,W504,F811,F821,W605,E402,F401,F405,E131,W503,E265,E999,F403

 > If you make a separate commit with this and repro steps for triggering
 the circular dependency bug I'd be happy to chat.

 don't put stuff in __init__

 > What benefit will that provide over what we presently have?

 flexibility

 I recently rewrote +/- 400 django unit tests to pytest, and yes, it's
 worth 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] #30331 [Obfuscation/Pluggable transport]: obfs4_bridgeline.txt file should contain complete bridge line

[Tor Bug Tracker & Wiki]

#30331: obfs4_bridgeline.txt file should contain complete bridge line
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  obfs4, bridge, anticensorship-   |  Actual Points:
  roadmap-can|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by gaba):

 * keywords:  obfs4, bridge => obfs4, bridge, anticensorship-roadmap-can


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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by 0xrichard):

 and this

 https://gitweb.torproject.org/stem.git/tree/stem/socket.py#n392

 haven't seen that in like 20 years

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 > I had a great day, found some things I would've done differently

 Fantastic! Glad you found this fruitful. :)

 >> File a ticket to discuss why you think we should change it.
 >
 > Just did

 Yup! But we still need to discuss both **what** stylistic aspects you
 think we should change and **why**. Stem should be conformant with PEP8
 except in the following respects...

 * Two space indentation rather than four.
 * Bare except clauses.
 * Space between keywords and arguments.

 Which of these do you strongly feel we should change and why?

 > and the circular imports :(

 If you make a separate commit with this and repro steps for triggering the
 circular dependency bug I'd be happy to chat.

 > and switch to pytest with fixtures

 What benefit will that provide over what we presently have?

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

Re: [tor-bugs] #30136 [Applications/Tor Browser]: Decide whether to use "Tor Browser" or "Tor Browser for Android" for mobile stable

[Tor Bug Tracker & Wiki]

#30136: Decide whether to use "Tor Browser" or "Tor Browser for Android" for 
mobile
stable
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-parity,  |  Actual Points:
  tbb-8.5-must, GeorgKoppen201904,   |
  TorBrowserTeam201905R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 These look good, but I noticed another bug we should fix (probably a fixup
 for #28622). When I built with `official` branding, I see the
 `about:firefox` favicon is using the `alpha` icon (blue-ish), instead of
 the `official` icon (purple-ish). I'm rebuilding now to confirm this
 wasn't caused by something else.

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by 0xrichard):

 > ...  before investing your time.

 I had a great day, found some things I would've done differently, like
 putting stuff in __init__.py

 > Decide which of the above PEP8 compliance rules you feel strongly that
 we should follow.

 [flake8]
 ignore = E501,W504,F811,F821,W605,E402,F401,F405,E131,W503,E265,E999,F403

 > File a ticket to discuss why you think we should change it.
 Just did

 > Once we've established a consensus on following the rule remove its
 ignore configuration from the file mentioned above. Stem's tests should
 now cite all the spots where we don't comply with it.

 That's up to you, you tell me. I got time :)

 > Make the adjustments (like your patch does) to correct the compliance
 issues.

 I'd be happy to

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by 0xrichard):

 and the circular imports :(

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by 0xrichard):

 and switch to pytest with fixtures

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

Re: [tor-bugs] #30218 [Metrics/CollecTor]: Add bandwidth files archiving to CollecTor

[Tor Bug Tracker & Wiki]

#30218: Add bandwidth files archiving to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/collector.git/commit/?h=task-30218=ad1bbc88c6fd5754384b7ab371ca0f2c879a6172
 commit ad1bbc8 in my task-30218 branch].

 If you want to try it, be sure to use a `metrics-lib-2.6.0-dev.jar` built
 with the #30369 fix.

 This branch worked just fine on my local machine for downloading two hours
 of bandwidth files. But I have to admit that I haven't tested it as
 thoroughly as I'd usually do. Let's be sure to give it more testing before
 we deploy this on the server.

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

Re: [tor-bugs] #30371 [Applications/Tor Browser]: Don't change the content provider name

[Tor Bug Tracker & Wiki]

#30371: Don't change the content provider name
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile   tbb-8.5-must|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  new => needs_review


Comment:

 Branch `bug30371_00` in my repo.

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

Re: [tor-bugs] #29757 [Applications/Tor Browser]: TBA: Delete Orbot Providers

[Tor Bug Tracker & Wiki]

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

 * keywords:  tbb-mobile, tbb-8.5-must, TorBrowserTeam201904 => tbb-mobile,
 TorBrowserTeam201904
 * status:  needs_review => new


Comment:

 Okay, new plan. There is an easier fix for getting this working on API 16.
 It seems if we drop the `content-provider.patch` for tor-android-service
 in tor-browser-build, then we avoid this problem. We can use #30371 for
 this change.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30371 [Applications/Tor Browser]: Don't change the content provider name

[Tor Bug Tracker & Wiki]

#30371: Don't change the content provider name
-+-
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile
 Severity:  Normal   |  tbb-8.5-must TorBrowserTeam201904
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As an immediate fix for the bug mentioned in ticket:29757#comment:2, we
 should delete the `tor-android-service` patch. This allows installing
 multiple versions of the app side-by-side.

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

Re: [tor-bugs] #29560 [Webpages/Research]: Create a Research Tools page

[Tor Bug Tracker & Wiki]

#29560: Create a Research Tools page
---+--
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer:  chelseakomlo, asn  |Sponsor:
---+--
Changes (by irl):

 * status:  accepted => needs_review
 * reviewer:   => chelseakomlo, asn


Comment:

 Please review my commit:

 https://gitweb.torproject.org/user/irl/research-
 web.git/commit/?h=task/29560=c9133768b0d4dba640dac66f127ad6e4dcbc5033

 I'm looking for a review of the content mostly. Am I forgetting any tools,
 could some description be better, is there a better link, did I spell all
 the words wrong, that sort of thing.

 If you're too busy, do unset yourself from reviewer. I'm not really sure
 who it is that should review this but let's figure it out.

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

Re: [tor-bugs] #30020 [Internal Services/Tor Sysadmin Team]: switch from our custom YAML implementation to Hiera

[Tor Bug Tracker & Wiki]

#30020: switch from our custom YAML implementation to Hiera
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29387   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i got a little tired of battling this, so I took a small break. I still
 migrated a few roles:

 {{{
 civicrm_ext_2018
 civicrm_int_2018
 civicrm_ext
 civicrm_int
 public_git
 rt
 svn
 metrics
 exonerator
 bridges
 trac
 mandos_server
 }}}

 many of those were easy marks: the ssl::service stuff were just a lot of
 copy-paste, which might have been better implemented by having a
 parametrized class with the node-specific parameters in hiera, something
 like:

 {{{
 class profile::ssl_web($name, $onion = false) {
ssl::service { $name: notify => Exec['service apache2 reload'], key =>
 true, onion => $onion }
 }
 }}}

 And in (say) `eugeni.torproject.org.yaml`, you would have:

 {{{
 profile::ssl_web::name: "lists.torproject.org"
 profile::ssl_web::onion: true
 classes:
   - profile::ssl_web
 }}}

 ... but I didn't want to overthink this just yet. plus we might want to
 manage those services more closely in Puppet eventually and such a class
 would just make it difficult. Besides, i suspect this would belong in the
 Apache module, not in a profile. '''And''' we should have a ''role'' in
 Hiera instead of a ''profile'', so we would end up creating the equivalent
 of the ''profile'' I ended up making anyways:

 {{{
 class profile::lists {
   ssl::service { 'lists.torproject.org':
 notify => Exec['service apache2 reload'],
 key=> true,
   }
 }
 }}}

 So I think it's the right conversion for now. I'm not converting the
 entire hierarchy to R/P/M just yet anyways, just switching to Hiera is
 enough work as it is.

 There are now 22 `has_role` calls left in the main `roles` class, down
 from around 50. Unfortunately, there is actually more roles in the
 `local.yaml` file (33) that I haven't considered or noticed, so we haven't
 crossed the magic halfway point just 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] #30368 [Obfuscation/Snowflake]: Run some tests to check reachability of snowflake proxies

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cohosh):

 Interestingly, the server that runs the standalone proxies is still TCP
 reachable from the VPS in China. I can telnet into ports 22, 80, and 443.

 For these tests I think we'll have to go the full bootstrapping route and
 send actual STUN traffic to the proxies.

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

Re: [tor-bugs] #30370 [Webpages/Website]: Unify headers and footers for all portals

[Tor Bug Tracker & Wiki]

#30370: Unify headers and footers for all portals
--+--
 Reporter:  antonela  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by antonela:

Old description:

> We should share the header and footer updates we are doing at
> http://torproject.org/ with the other portals:
>
> support.torproject.org/
> newsletter.torproject.org/
> tb-manual.torproject.org/

New description:

 We should share header and footer updates we are doing at
 http://torproject.org/ with the other portals:

 support.torproject.org/
 newsletter.torproject.org/
 tb-manual.torproject.org/

--

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

[tor-bugs] #30370 [Webpages/Website]: Unify headers and footers for all portals

[Tor Bug Tracker & Wiki]

#30370: Unify headers and footers for all portals
--+--
 Reporter:  antonela  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should share the header and footer updates we are doing at
 http://torproject.org/ with the other portals:

 support.torproject.org/
 newsletter.torproject.org/
 tb-manual.torproject.org/

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

[tor-bugs] #30369 [Metrics/Library]: Fix regular expression in descriptor parser to correctly recognize bandwidth files

[Tor Bug Tracker & Wiki]

#30369: Fix regular expression in descriptor parser to correctly recognize
bandwidth files
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We're using a regular expression on the first 100 characters of a
 descriptor to recognize bandwidth files. More specifically, if a
 descriptor starts with ten digits followed by a newline, we parse it as a
 bandwidth file. (This is ugly, but the legacy bandwidth file format
 doesn't give us much of a choice.)

 This regular expression is broken. The regular expression we want is one
 that matches the first 100 characters of a descriptor, which ours didn't
 do.

 Suggested fix:

 {{{
 diff --git
 a/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 b/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 index 119fe09..08ac909 100644
 ---
 a/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 +++
 b/src/main/java/org/torproject/descriptor/impl/DescriptorParserImpl.java
 @@ -132,7 +132,7 @@ public class DescriptorParserImpl implements
 DescriptorParser {
sourceFile);
  } else if (fileName.contains(LogDescriptorImpl.MARKER)) {
return LogDescriptorImpl.parse(rawDescriptorBytes, sourceFile,
 fileName);
 -} else if (firstLines.matches("^[0-9]{10}\\n")) {
 +} else if (firstLines.matches("(?s)[0-9]{10}\\n.*")) {
/* Identifying bandwidth files by a 10-digit timestamp in the first
 line
 * breaks with files generated before 2002 or after 2286 and when
 the next
 * descriptor identifier starts with just a timestamp in the first
 line
 }}}

 Explanation:

  - We don't need to start the pattern with `^`, because the regular
 expression needs to match the whole string anyway.
  - The `(?s)` part enables the dotall mode: ''"In dotall mode, the
 expression . matches any character, including a line terminator. By
 default this expression does not match line terminators. Dotall mode can
 also be enabled via the embedded flag expression (?s). (The s is a
 mnemonic for "single-line" mode, which is what this is called in Perl.)"''
  - We need to end the pattern with `.*` to match any characters following
 the first newline, which also includes newlines due to the previously
 enabled dotall mode.

 I'll create a branch for this in a minute.

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

Re: [tor-bugs] #30369 [Metrics/Library]: Fix regular expression in descriptor parser to correctly recognize bandwidth files

[Tor Bug Tracker & Wiki]

#30369: Fix regular expression in descriptor parser to correctly recognize
bandwidth files
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-30369=016d49f5142561476185105ef770006d9635f91e
 commit 016d49f in my task-30369 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] #26838 [Webpages/Website]: Port the research portal content to Hugo

[Tor Bug Tracker & Wiki]

#26838: Port the research portal content to Hugo
--+
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  research,ux-team  |  Actual Points:
Parent ID:  #26836| Points:
 Reviewer:|Sponsor:
--+
Changes (by irl):

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


Comment:

 Replying to [comment:9 irl]:
 > Ok, time to juggle the git branches.
 >
 > master -> oldmaster
 > staging -> master
 >
 > Move the existing research website contents out of the way
 >
 > Deploy new site to production
 >
 > What could go wrong?

 Excluding the permissions hiccup above, nothing went wrong.

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

Re: [tor-bugs] #29560 [Webpages/Research]: Create a Research Tools page

[Tor Bug Tracker & Wiki]

#29560: Create a Research Tools page
---+--
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * status:  new => accepted


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

Re: [tor-bugs] #26838 [Webpages/Website]: Port the research portal content to Hugo

[Tor Bug Tracker & Wiki]

#26838: Port the research portal content to Hugo
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  research,ux-team  |  Actual Points:
Parent ID:  #26836| Points:
 Reviewer:|Sponsor:
--+--

Comment (by anarcat):

 @irl had permission issues while deploying the site in production. i have
 done the following maneuver on the server (staticiforme):

 {{{
 cd /srv/research.torproject.org && mv htdocs htdocs-old && mkdir htdocs &&
 chmod g+ws htdocs && chown :torresearch htdocs
 }}}

 After looking into the htdocs-old (11MB), I figured it could also be
 removed so that's 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

Re: [tor-bugs] #30304 [Applications/Tor Browser]: Browser locale can be obtained via DTD strings

[Tor Bug Tracker & Wiki]

#30304: Browser locale can be obtained via DTD strings
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by acat):

 Here is a patch: https://github.com/acatarineu/tor-browser/commit/30304.

 https://github.com/acatarineu/tor-browser/commit/30304#diff-
 52beed12eac86326f289d0b43ffadb3bL215 should remove the exception that
 allows all DTDs to be loaded. In practice, removing this I think would
 only break legacy extensions. For example, it breaks `about:tor`, because
 its locale files are not contentaccessible and cannot be loaded anymore.

 With that change, contentaccessible=yes dtds can still be loaded from web
 content, and therefore still leaking browser language.
 https://github.com/acatarineu/tor-browser/commit/30304#diff-
 318b0aeb24e87bc216c590860a030b58R524 should fix that, forbidding any
 `chrome://*/locale/*` URIs to be loaded from web content,
 contentaccessible or not.

 This change breaks many `about:*` pages, since they rely on the locales
 being contentaccessible. The change here: https://github.com/acatarineu
 /tor-browser/commit/30304#diff-d637999733ba943ba8fc3b01c451df66R866 tries
 to fix that (and also previously mentioned about:tor breakage), allowing
 `about:*` pages to always load `chrome://*` resources.

 I'm making a couple of assumptions I would need to check. First, I'm
 assuming the only way to load locale DTDs is via `chrome://*/locale/*`. If
 there is a way to load them via `resource://*` or some `chrome` URIs that
 do not follow that structure, I think the patch would not work. Second,
 there is no way to load a resource from web content as `about:*`. If this
 was possible we could bypass the protection, because we are adding an
 exception for about pages.

 Then, there is breakage again. Since Firefox relies on several
 `resource://` and `chrome://` URIs to load in web content for some
 features, these changes might break something. I think #8725 and
 corresponding https://bugzilla.mozilla.org/show_bug.cgi?id=863246 are
 relevant here. Arthur mentions in bugzilla several features that use these
 (video controls, image display, text-box resizing, and directory listing).
 I checked this and they work with this patch in ESR60 (except text-box
 resizing, not sure which one is that).

 So I could not find this breaking in current ESR60. BUT, the same patch
 breaks several things in Firefox Nightly. First, the browser UI itself
 (for some reason it's loading `chrome://...` dtds from `moz-nullprincipal`
 origins). Video controls are also broken, displaying xml with errors
 (because the locale DTD could not be loaded).

 I think I'll update the bugzilla ticket with a patch for central (even if
 it's broken), and ni ckerschb as Tom suggested.

 A couple of tests: https://acatarineu.github.io/fp/locale.html
 https://acatarineu.github.io/fp/locale_nullprincipal.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] #29374 [Metrics/Onionperf]: Analysis files sometimes present negative numbers in the payload_progress field

[Tor Bug Tracker & Wiki]

#29374: Analysis files sometimes present negative numbers in the 
payload_progress
field
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

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


Comment:

 Thanks for creating that ticket. Closing this one!

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

Re: [tor-bugs] #30357 [- Select a component]: find out if HTTPSEverythwere language mapping should follow the changes done with torbutton

[Tor Bug Tracker & Wiki]

#30357: find out if HTTPSEverythwere language mapping should follow the changes
done with torbutton
---+--
 Reporter:  emmapeel   |  Owner:  emmapeel
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  - Select a component   |Version:
 Severity:  Normal | Resolution:
 Keywords:  localization, httpseverywhere  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by emmapeel):

 No, it would mean to call the translations just like in Firefox-ESR:
 https://hg.mozilla.org/l10n-central

 So I think it will help HTTPS Everywhere to appear localized in more
 languages.

 Just as Tor Browser follows the Mozilla language mapping, so should
 HTTPSEverywhere, right?

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

Re: [tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
---+
 Reporter:  0xrichard  |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  dev|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi 0xrichard, thanks for the patch! In this case though I kinda wish you'd
 talked with me before investing your time. Stem runs pycodestyle as part
 of its tests, and already complies with PEP8 in most regards. The ways in
 which it differs (for instance, two space indentation) is intentional...

 https://gitweb.torproject.org/stem.git/tree/test/settings.cfg#n95

 If you'd care to push for us to be more compliant that's fine, but the
 approach we should take is...

 1. Decide which of the above PEP8 compliance rules you feel strongly that
 we should follow.

 2. File a ticket to discuss why you think we should change it.

 3. Once we've established a consensus on following the rule remove its
 ignore configuration from the file mentioned above. Stem's tests should
 now cite all the spots where we don't comply with it.

 4. Make the adjustments (like your patch does) to correct the compliance
 issues.

 Does that make sense?

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

Re: [tor-bugs] #30357 [- Select a component]: find out if HTTPSEverythwere language mapping should follow the changes done with torbutton

[Tor Bug Tracker & Wiki]

#30357: find out if HTTPSEverythwere language mapping should follow the changes
done with torbutton
---+--
 Reporter:  emmapeel   |  Owner:  emmapeel
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  - Select a component   |Version:
 Severity:  Normal | Resolution:
 Keywords:  localization, httpseverywhere  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by legind):

 The structure of translations for HTTPS Everywhere has always been kind of
 elusive to me.  Does this mean that we may lose translations for the
 latest Firefox (stable) locales?  We don't want that since Tor Browser is
 just a subset of our users.

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

Re: [tor-bugs] #26838 [Webpages/Website]: Port the research portal content to Hugo

[Tor Bug Tracker & Wiki]

#26838: Port the research portal content to Hugo
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  research,ux-team  |  Actual Points:
Parent ID:  #26836| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Ok, time to juggle the git branches.

 master -> oldmaster
 staging -> master

 Move the existing research website contents out of the way

 Deploy new site to production

 What could go wrong?

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

Re: [tor-bugs] #30368 [Obfuscation/Snowflake]: Run some tests to check reachability of snowflake proxies (was: Run some tests to check reachability of snowflake proxies in China)

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 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] #30368 [Obfuscation/Snowflake]: Run some tests to check reachability of snowflake proxies in China

[Tor Bug Tracker & Wiki]

#30368: Run some tests to check reachability of snowflake proxies in China
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Our standalone proxies were recently blocked in China: #30350

 We should start running some probe tests like we are for obfs4 to see
 whether this blocking was a one-off event and detect blocking of new proxy
 instances.

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

Re: [tor-bugs] #28152 [Applications/GetTor]: Gettor code refactor with Python Twisted

[Tor Bug Tracker & Wiki]

#28152: Gettor code refactor with Python Twisted
-+--
 Reporter:  ilv  |  Owner:  hiro
 Type:  enhancement  | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Major| Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor19
-+--
Changes (by gaba):

 * reviewer:   => phw


Comment:

 Adding phw to review this code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Obfuscation/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
---+---
 Reporter:  oarel  |  Owner:  arlolra
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team tor-pt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by antonela):

 * Attachment "snowflake-icon.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] #23888 [Obfuscation/Snowflake]: Creating a Snowflake WebExtension addon

[Tor Bug Tracker & Wiki]

#23888: Creating a Snowflake WebExtension addon
---+---
 Reporter:  oarel  |  Owner:  arlolra
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team tor-pt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by antonela):

 * Attachment "browser_extension.sketch" 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] #29757 [Applications/Tor Browser]: TBA: Delete Orbot Providers

[Tor Bug Tracker & Wiki]

#29757: TBA: Delete Orbot Providers
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  new => needs_review


Comment:

 I have a branch for review in my tor-browser-build repo, `bug29757_00`. It
 simply deletes the class file (DataService.java) and deletes the code in
 TorServices where it is referenced. I think a better patch involves adding
 a preference (or something similar) where we can specify we don't want the
 additional content providers and tor-android-service simply skips the
 lines where DataService is configured, but I think we can work on that
 later.

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

Re: [tor-bugs] #30142 [Obfuscation/Snowflake]: Remove serene from snowflake.git commit access?

[Tor Bug Tracker & Wiki]

#30142: Remove serene from snowflake.git commit access?
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 Marking this discussion as done. Filed a services ticket at #30367.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30367 [Internal Services/Service - git]: Remove serene's permission to push to /pluggable-transports/snowflake.git

[Tor Bug Tracker & Wiki]

#30367: Remove serene's permission to push to 
/pluggable-transports/snowflake.git
-+
 Reporter:  dcf  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:  snowflake
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Following discussion at #30142, please remove "serene" from the set of
 users who can push to /pluggable-transports/snowflake.git.
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCgAdFiEEeXoyauxKR4rwUMw64rk9gVzTiOUFAlzLHb8ACgkQ4rk9gVzT
 iOVVww/9F3avxwRHOQ5fyZNmgphoZtSjV9RGO6tvCTFK+jrOEIIeHisfcYRDqN3S
 BAx3pPSyOEv6RbgwTFcjRFjF+cTKBw+bRYSDS7a+lC0jMewwnWLvfGP4+7RPDFMG
 Rcg2PMvcuhid6kxPX5wDLfyfwhor9zI2a1qhvJanqUtFNwv1Mz9LMQArQhLSIjgc
 CulYmbOoP2BUXH0C35J+pg02wb7WEiDKSHZIWUHNBPqGn6Ly9hQX0iiDujx2EtuS
 IODTxg5mHzCIv5fLt8u2huJchrfRFQHE0nJEqYaKNUWQD/k0j3h/dIjyfTjt8wZ6
 oqoEa/W0DxFm8mf5sNCZ/4IMVfpBwDrGyv2z15iv1/b9mMNHZ8qbjfijZGe2UTTL
 wHX4cu8UKiH9dJAD3mQc2V91k1/Omeyd1vvzijINp9ofjEJzL3PJtT7wklOW6B6D
 74PC/onhEwp7vPDY4fR2hEEJ3fDEkfzzk7ecZBlbNz1vTP9NsQmBSefiPzV8Pe/3
 xKbZ5sL4VwAphd50C2yhcH725EsF0+Ho+Dd52hTh/4kYdT/94YFd7Qt3za170Nq2
 Z9gXWUaM1AhFIBgSu4oIIOxf/uZY0Vg1F1JgqBzxYa2f/OJbrGtb4wt05cK62Yc3
 TM4wSJ0u6TpK2ig33EXGvIdVtbqSQIhr6816xlQVhiyVzF4Ii0U=
 =dzBw
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #26673 [Metrics/Onionperf]: Record download times of smaller file sizes from partial completion times

[Tor Bug Tracker & Wiki]

#26673: Record download times of smaller file sizes from partial completion 
times
-+-
 Reporter:  karsten  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  user-experience, |  Actual Points:
  acute-2019-q1-planned  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-

Comment (by acute):

 Replying to [comment:5 karsten]:

 >  1. Can we reprocess existing logs to include these partial completion
 timestamps for past measurements, maybe when we reprocess logs for #29787?
 (I'm happy to do the actual reprocessing, I'm just asking if you see any
 problems with that.)

 Yes, if we have all the logs reprocessing should be easy, I have some code
 to do this  already for testing the analysis changes - which can be
 bundled into a script!

 >  2. I think the goal is to change the weights for making 50k/1m/5m
 downloads towards making more 5m downloads and still obtaining 50k/1m
 results from these new timestamps. Should we change weights in several
 steps to ensure we're not overloading anything? Like, from 12/2/1 over
 6/2/1 and 2/1/1 to 0/0/1?
 This is the next step - following this week's metrics team meeting, this
 is ready to do whenever we're ready with the changes downstream.

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

Re: [tor-bugs] #30138 [Obfuscation/Snowflake]: Remove serene from snowflake bridge admin

[Tor Bug Tracker & Wiki]

#30138: Remove serene from snowflake bridge admin
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 I ran
 {{{
 deluser --remove-home serene
 delgroup serene
 }}}
 and edited /etc/ssh/sshd_config:
 {{{
 AllowUsers dcf arlolra cohosh phw
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 Replying to [comment:2 antonela]:
 > Following the specs, we don't have user/password, end-users just have a
 private key. So, I updated the first user story's UI.
 >
 >

 Looks good. Not sure how we can do better than "Private Key" but perhaps
 we should. Perhaps we can write "Personal key" or "key" and then have more
 info in a "?" box?
 No idea...

 >
 > We should work on this validation. I made a first approach for this
 content, please feel free to suggest/add/remove any of this lines:
 >
 > ||= Type =||= Error =||= UI Message =||
 > || User Input ||incomplete form|| Please, enter your private key ||
 > || User Input ||over/under character or word count|| Must have 52
 characters ||
 > || System Error ||misspelled errors|| The private key is wrong. Try
 again. ||
 > || System Error ||connectivity issues|| There was an error. Check your
 internet connection and try again. ||
 > || System Error ||failure to load|| There was an error handling your
 request. Try again. ||
 >
 >
 > Which else error scenario should we consider?
 >
 >

 The first two errors can indeed be detected and IMO should be detected.

 The `misspelled errors` can be detected (by checking whether we could
 decrypt the descriptor with the key), but depending on how communication
 channel between TB<->Tor works, we might not learn the result on time to
 keep the auth dialog open. So we would have to respawn the auth dialog to
 throw the error. Does this make sense, and is it ok?

 Same for `connectivity issues` and `failure to load` but perhaps this
 should be handled the same way as #30025?

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

Re: [tor-bugs] #30350 [Obfuscation/Snowflake]: Hello, in China, currently, Tor Browser 8.5a11 version can't connect to Tor network through Snowflake bridge.

[Tor Bug Tracker & Wiki]

#30350: Hello, in China, currently, Tor Browser 8.5a11 version can't connect to 
Tor
network through Snowflake bridge.
---+--
 Reporter:  amiableclarity2011 |  Owner:  cohosh
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:10 cohosh]:
 > This makes sense to me, I think we do need to do something about item 2
 as well though. I wasn't able to test the behaviour of tor browser at the
 VPS but just the Tor client was having trouble quickly deciding whether or
 not the proxy was being blocked. I suppose this won't be as big an issues
 when we have more diverse proxies though.

 No disagreement there. Snowflake can do better about detecting a lack of
 connectivity. Actually it's kind of a general thing that affects more than
 just Snowflake. See #24640 for meek for example. The PT interface was
 designed with a mindset of obfs4-like transport that make a single TCP
 connection to a single bridge and always have a well-defined connectedness
 state--it doesn't map perfectly onto transports that don't work like that.
 I think there are bugs on the tor side as well--see comment:3:ticket:26891
 where deleting a state file made the connection start working, which looks
 like #11301 even though that is supposed to be fixed.

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

Re: [tor-bugs] #30168 [Applications/Tor Browser]: Clean up e.g. tor-browser-build after shipping TOPL

[Tor Bug Tracker & Wiki]

#30168: Clean up e.g. tor-browser-build after shipping TOPL
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 May be a silly question, but does the firefox build still depend on orbot?
 (orbot is still listed in `config`, but does Orbot provide something we
 don't get from tor-android-service+TOPL)?

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

Re: [tor-bugs] #30366 [Obfuscation/Snowflake]: Whether China's firewall can recognize the characteristic of the traffic which flows to Snowflake proxies or not.

[Tor Bug Tracker & Wiki]

#30366: Whether China's firewall can recognize the characteristic of the traffic
which flows to Snowflake proxies or not.
---+---
 Reporter:  amiableclarity2011 |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Immediate  |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dcf):

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


Comment:

 Duplicate of #30350.

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

Re: [tor-bugs] #26597 [Metrics/Onionperf]: Investigate and document additional overhead for first hop when not using guards

[Tor Bug Tracker & Wiki]

#26597: Investigate and document additional overhead for first hop when not 
using
guards
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Note to self: think about what to do with this ticket now.

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

Re: [tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #2   | Points:  7
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * owner:  (none) => asn
 * status:  new => assigned


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

[tor-bugs] #30363 [Core Tor/Tor]: prop289: Implement FlowCtrl protover value

[Tor Bug Tracker & Wiki]

#30363: prop289: Implement FlowCtrl protover value
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop289, sendme
Actual Points:|  Parent ID:  #26288
   Points:  1 |   Reviewer:
  Sponsor:  SponsorV  |
--+
 See prop289 section 4.3.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30366 [Obfuscation/Snowflake]: Whether China's firewall can recognize the characteristic of the traffic which flows to Snowflake proxies or not.

[Tor Bug Tracker & Wiki]

#30366: Whether China's firewall can recognize the characteristic of the traffic
which flows to Snowflake proxies or not.
+---
 Reporter:  amiableclarity2011  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Component:  Obfuscation/Snowflake
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 This morning, in China, my connection to Tor network through Snowflake
 bridge was terminated within 30 minutes. Maybe China's firewall can
 recognize the characteristic of the traffic which flows to Snowflake
 proxies and quickly block the Snowflake proxies that I use.

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

Re: [tor-bugs] #15516 [Core Tor/Tor]: Consider rate-limiting INTRODUCE2 cells when under load

[Tor Bug Tracker & Wiki]

#15516: Consider rate-limiting INTRODUCE2 cells when under load
-+-
 Reporter:  special  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  SponsorU-deferred, tor-dos, tor-hs,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2 |
Parent ID:  #2   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by asn):

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


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

Re: [tor-bugs] #25876 [Applications/Tor Browser]: Source release tarballs for Tor Browser

[Tor Bug Tracker & Wiki]

#25876: Source release tarballs for Tor Browser
+--
 Reporter:  attila  |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201903R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by attila):

 Replying to [comment:12 gk]:
 > attila: Are you good if we only keep the latest two releases? And
 putting them on dist.torproject.org would work as well for you?

 Sorry for the belated reply.  Yes, this would work great.  I see this is
 happening for the alpha
 releases already!  Looking forward to dropping my git-wrangling when this
 hits the stable releases
 as well... thanks a lot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30365 [Core Tor/Tor]: prop289: Update tor-spec.txt with authenticated SENDME spec

[Tor Bug Tracker & Wiki]

#30365: prop289: Update tor-spec.txt with authenticated SENDME spec
--+---
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec, prop289, sendme
Actual Points:|  Parent ID:  #26288
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+---
 Basically either merge proposal 289 into tor-spec.txt or create sendme-
 spec.txt which should then be referenced within tor-spec.txt.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30364 [Core Tor/Tor]: prop289: Add consensus param to use or not SENDME v1 for one-hop directory download

[Tor Bug Tracker & Wiki]

#30364: prop289: Add consensus param to use or not SENDME v1 for one-hop 
directory
download
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  assigned
 Priority:  Very High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop289, sendme
Actual Points:|  Parent ID:  #26288
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 See proposal 289 section 4.5 which is about adding a consensus param that
 controls the minimum version to use when doing one-hop directory
 connections.

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2, tor-spec   |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * keywords:
 prop289, 035-roadmap-master, 035-triaged-in-20180711, prop289
 -assigned-sponsor-v, 041-proposed-on-roadmap, network-team-
 roadmap-2019-Q1Q2, tor-spec asn-merge
 =>
 prop289, 035-roadmap-master, 035-triaged-in-20180711, prop289
 -assigned-sponsor-v, 041-proposed-on-roadmap, network-team-
 roadmap-2019-Q1Q2, tor-spec


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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2, tor-spec asn-merge |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by asn):

 Merged! Keeping the ticket open. I haven't merged the spec changes since
 comment:41 says that there are needed additions.

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

Re: [tor-bugs] #29374 [Metrics/Onionperf]: Analysis files sometimes present negative numbers in the payload_progress field

[Tor Bug Tracker & Wiki]

#29374: Analysis files sometimes present negative numbers in the 
payload_progress
field
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Replying to [comment:13 karsten]:
 > Great!
 >
 > Let's leave this ticket open until that other ticket exists, and let's
 include a reference here when closing this ticket. Thanks!
 Created ticket #30362.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30362 [Metrics/Onionperf]: OnionPerf TGen parser needs reworking

[Tor Bug Tracker & Wiki]

#30362: OnionPerf TGen parser needs reworking
-+---
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Metrics/Onionperf
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
 OP builds analysis files from TGen and Tor logs. As described in #29374,
 the OP TGen parser only looks at `[transfer-*]` lines in the TGen files,
 which does not correctly calculate start times for transfers which have
 failed due to errors.
 The parser should take into account the source/proxy ports and record the
 start time of a transfer. This will help build a foundation for completing
 #29787, and include error code combinations in from both tor/tgen logs in
 the produced *.tpf files.

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

Re: [tor-bugs] #26838 [Webpages/Website]: Port the research portal content to Hugo

[Tor Bug Tracker & Wiki]

#26838: Port the research portal content to Hugo
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  research,ux-team  |  Actual Points:
Parent ID:  #26836| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Comments from antonela were:

 * make safety board page two-column like support.torproject.org
 * col-md-6 for research group cards
 * use pandoc for rendering bibliography/tech reports list

 The first two can be done now, the last one is a bigger thing.

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

Re: [tor-bugs] #30345 [Core Tor/Tor]: Move remaining dirauth files into dirauth module

[Tor Bug Tracker & Wiki]

#30345: Move remaining dirauth files into dirauth module
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  asn-merge |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-must
--+
Changes (by asn):

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


Comment:

 Merged.

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

Re: [tor-bugs] #30328 [Core Tor/Tor]: Fix Coverity CID 1444769

[Tor Bug Tracker & Wiki]

#30328: Fix Coverity CID 1444769
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ahf):

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


Comment:

 Duplicate of #30361

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

Re: [tor-bugs] #30342 [Core Tor/Tor]: 9 dephects on prob_distr.c (April 2019)

[Tor Bug Tracker & Wiki]

#30342: 9 dephects on prob_distr.c (April 2019)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prob-distr coverity  |  Actual Points:
Parent ID:   | Points:  0.4
 Reviewer:   |Sponsor:
-+
Changes (by asn):

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


Comment:

 Oook. Just got `16 defect(s), reported by Coverity Scan earlier, were
 marked fixed in the recent build analyzed by Coverity Scan.` in the latest
 email, and all of these seem to be fixed. Thanks!

 Created #30361 for two new ones.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30361 [Core Tor/Tor]: CID 1444908: MISSING_LOCK / CID 1444769: TAINTED_SCALAR

[Tor Bug Tracker & Wiki]

#30361: CID 1444908: MISSING_LOCK / CID 1444769: TAINTED_SCALAR
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  coverity
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Got two new coverity issues:

 {{{
 *** CID 1444908:  Concurrent data access violations  (MISSING_LOCK)
 /src/test/rng_test_helpers.c: 190 in testing_enable_prefilled_rng()
 184 {
 185   tor_assert(buflen > 0);
 186   rng_mutex = tor_mutex_new();
 187
 188   prefilled_rng_buffer = tor_memdup(buffer, buflen);
 189   prefilled_rng_buflen = buflen;
 >>> CID 1444908:  Concurrent data access violations  (MISSING_LOCK)
 >>> Accessing "prefilled_rng_idx" without holding lock
 "tor_mutex_t.mutex". Elsewhere, "prefilled_rng_idx" is accessed with
 >>> "tor_mutex_t.mutex" held 3 out of 4 times (1 of these accesses
 strongly imply that it is necessary).
 190   prefilled_rng_idx = 0;
 191
 192   MOCK(crypto_rand, crypto_rand_prefilled);
 193   MOCK(crypto_strongest_rand_, mock_crypto_strongest_rand);
 194 }
 195

 ** CID 1444769:  Insecure data handling  (TAINTED_SCALAR)

 

 *** CID 1444769:  Insecure data handling  (TAINTED_SCALAR)
 /src/feature/nodelist/microdesc.c: 540 in microdesc_cache_reload()
 534   }
 535
 536   journal_content = read_file_to_str(cache->journal_fname,
 537  RFTS_IGNORE_MISSING, );
 538   if (journal_content) {
 539 cache->journal_len = (size_t) st.st_size;
 >>> CID 1444769:  Insecure data handling  (TAINTED_SCALAR)
 >>> Passing tainted variable "journal_content" to a tainted sink.
 540 warn_if_nul_found(journal_content, cache->journal_len, 0,
 541   "reading microdesc journal");
 542 added = microdescs_add_to_cache(cache, journal_content,
 543 journal_content+st.st_size,
 544 SAVED_IN_JOURNAL, 0, -1,
 NULL);
 545 if (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] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2, tor-spec asn-merge |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by dgoulet):

 * keywords:
 prop289, 035-roadmap-master, 035-triaged-in-20180711, prop289
 -assigned-sponsor-v, 041-proposed-on-roadmap, network-team-
 roadmap-2019-Q1Q2, tor-spec
 =>
 prop289, 035-roadmap-master, 035-triaged-in-20180711, prop289
 -assigned-sponsor-v, 041-proposed-on-roadmap, network-team-
 roadmap-2019-Q1Q2, tor-spec asn-merge
 * status:  needs_review => merge_ready


Comment:

 Integration tests went well! Now, this lacks two things:

 * `FlowCtrl` protover value.
 * The one-hop circuit to a directory cache (download consensus) and its
 consensus param.

 nickm and I discussed it on IRC and we'll do that once this is merged so
 we don't pile up more things on this already big/non-trivial branch.
 However, we will not release both features apart, they need to all go in
 the same release. I'll open these tickets and made them child of this
 parent ticket.

 Which means that once this is merged, keep this parent ticket open until
 we merge the children.

 Final PR: https://github.com/torproject/tor/pull/986
 Branch: `ticket26288_041_03`
 Spec: `ticket26288_01` <-- be careful, has a fixup commit.

 Once everything is good, we'll need a tor-spec.txt (or maybe a new sendme-
 spec.txt?) patch to integrate the proposal officially into the spec.

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

Re: [tor-bugs] #30345 [Core Tor/Tor]: Move remaining dirauth files into dirauth module

[Tor Bug Tracker & Wiki]

#30345: Move remaining dirauth files into dirauth module
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-must
--+

Comment (by nickm):

 ok, CI has passed.

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

Re: [tor-bugs] #30258 [Obfuscation/Snowflake]: Snowflake proxy stops working during browsing session

[Tor Bug Tracker & Wiki]

#30258: Snowflake proxy stops working during browsing session
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 (putting this in needs review to have someone else confirm that #30206
 resolved the issue)

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

Re: [tor-bugs] #30356 [Obfuscation/Snowflake]: Hello, this morning, in China, the connection to Tor network through Snowflake bridge was suddenly terminated.

[Tor Bug Tracker & Wiki]

#30356: Hello, this morning, in China, the connection to Tor network through
Snowflake bridge was suddenly terminated.
---+---
 Reporter:  amiableclarity2011 |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Immediate  |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cohosh):

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


Comment:

 Hi,
 Thank you for making these tickets and helping make Tor available to more
 people in China.

 We're tracking your updates all on ticket #30350, so there's no need to
 make more tickets. It's going to take us a while to resolve this issue
 because it relies on more people running proxies, since all of the current
 snowflake proxies have been blocked.

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

Re: [tor-bugs] #27385 [Obfuscation/Snowflake]: https://snowflake.torproject.org/embed is confusing

[Tor Bug Tracker & Wiki]

#27385: https://snowflake.torproject.org/embed is confusing
---+
 Reporter:  cypherpunks3   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  snowflake, ux-team |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

 * cc: irl (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] #30346 [Internal Services/Service - nextcloud]: Can't create or open riseup pads in Nextcloud

[Tor Bug Tracker & Wiki]

#30346: Can't create or open riseup pads in Nextcloud
-+-
 Reporter:  alsmith  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

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


Comment:

 Summary: A service which shouldn't have been there from the beginning was
 removed.

 Way forward: If this service is valuable, we (Tor) should find a way of
 implementing it. A good start would be a description of the needed service
 in general terms written down in a new ticket.

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

Re: [tor-bugs] #30360 [Internal Services/Service - nextcloud]: Please make the Deck API available

[Tor Bug Tracker & Wiki]

#30360: Please make the Deck API available
-+-
 Reporter:  ln5  |  Owner:
 |  nextcloud-admin@…
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ln5):

 gaba: Is it possible that the API is already available? I haven't checked.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30360 [Internal Services/Service - nextcloud]: Please make the Deck API available

[Tor Bug Tracker & Wiki]

#30360: Please make the Deck API available
-+-
 Reporter:  ln5  |  Owner:  nextcloud-admin@…
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Internal Services/Service -
 |  nextcloud
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Moved from #30330.

 From gaba:

 Hey! It is not possible to import boards in deck unless the API is
 available. And we have a few boards in storm/wekan right now that would be
 good not to have to migrate by hand.

 Can we have the API available for deck?
 https://deck.readthedocs.io/en/latest/API

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

Re: [tor-bugs] #30350 [Obfuscation/Snowflake]: Hello, in China, currently, Tor Browser 8.5a11 version can't connect to Tor network through Snowflake bridge.

[Tor Bug Tracker & Wiki]

#30350: Hello, in China, currently, Tor Browser 8.5a11 version can't connect to 
Tor
network through Snowflake bridge.
---+--
 Reporter:  amiableclarity2011 |  Owner:  cohosh
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cohosh):

 > I'm not sure item 3, tracking where proxies are blocked, is necessarily
 a priority. Round-the-clock proxy-go was never meant to be a permanent
 thing, only a stopgap until we have actual organic proxies (#20813). The
 idea is that eventually we don't rely on long-lived proxies running at
 static IP addresses, because if we do that we're playing the bridge
 distribution game, and doing it worse than BridgeDB does. IMO the browser
 extension (#23888) is the priority for getting actually diverse
 snowflakes.
 This makes sense to me, I think we do need to do something about item 2 as
 well though. I wasn't able to test the behaviour of tor browser at the VPS
 but just the Tor client was having trouble quickly deciding whether or not
 the proxy was being blocked. I suppose this won't be as big an issues when
 we have more diverse proxies though.

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

Re: [tor-bugs] #30345 [Core Tor/Tor]: Move remaining dirauth files into dirauth module

[Tor Bug Tracker & Wiki]

#30345: Move remaining dirauth files into dirauth module
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-must
--+

Comment (by nickm):

 (There is a fixup commit on this branch; the branch to merge is
 `more_dirauth_modularity_squashed`)

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

Re: [tor-bugs] #30330 [Internal Services/Service - nextcloud]: When do we upgrade to 16?

[Tor Bug Tracker & Wiki]

#30330: When do we upgrade to 16?
-+-
 Reporter:  ln5  |  Owner:  micah
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

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


Comment:

 Replying to [comment:3 micah]:
 > plan to do this upgrade this weekend

 Thanks!

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

Re: [tor-bugs] #30345 [Core Tor/Tor]: Move remaining dirauth files into dirauth module

[Tor Bug Tracker & Wiki]

#30345: Move remaining dirauth files into dirauth module
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-must
--+

Comment (by nickm):

 test-stem broke; poking it to see if it works.

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

Re: [tor-bugs] #30342 [Core Tor/Tor]: 9 dephects on prob_distr.c (April 2019)

[Tor Bug Tracker & Wiki]

#30342: 9 dephects on prob_distr.c (April 2019)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prob-distr coverity  |  Actual Points:
Parent ID:   | Points:  0.4
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I've tried manually kicking one off.  (Our current coverity setup is a
 cronjob on my development machine.)  I'm still having to tell it to ignore
 certificate verification, since curl still doesn't like scan.coverity.com.

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

Re: [tor-bugs] #30239 [Applications/Tor Browser]: TBA: Gracefully handle auto-restart after crash

[Tor Bug Tracker & Wiki]

#30239: TBA: Gracefully handle auto-restart after crash
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile tbb-8.5-must  |  Actual Points:
  TorBrowserTeam201905R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks for the deatailed explanation and instructions. The changes look
 good to me. I've cherry-picked them onto `tor-browser-60.6.1esr-8.5-1`
 (commits 7b6b87d4766fbf7642cd967d0c37dbe0ddef8fdd,
 2665a59cc56b12e27ac050e31b2db65b66cd1878, and
 8a9df95b91c15cd1923833acadceb0dce777a665).

 I was not able to test the patch as much as I wanted, though. Using `kill`
 is not possible on my non-rooted device and `force-stop` does not trigger
 the bug for 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] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt refactoring dgoulet-  |  Actual Points:
  merge  |
Parent ID:  #29209   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => merge_ready
 * reviewer:   => nickm


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

Re: [tor-bugs] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt refactoring dgoulet-  |  Actual Points:
  merge  |
Parent ID:  #29209   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * sponsor:   => Sponsor31-can


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

Re: [tor-bugs] #30213 [Core Tor/Tor]: Remove sudo: false from Travis

[Tor Bug Tracker & Wiki]

#30213: Remove sudo: false from Travis
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, tor-ci 040-backport  |  Actual Points:
  035-backport 034-backport 029-backport |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

 * keywords:  technical-debt, tor-ci =>
 technical-debt, tor-ci 040-backport 035-backport 034-backport
 029-backport
 * milestone:  Tor: 0.4.1.x-final => Tor: 0.4.0.x-final


Comment:

 Okay; I've merged this into master. Marking for backport.

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

Re: [tor-bugs] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt refactoring dgoulet-  |  Actual Points:
  merge  |
Parent ID:  #29209   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Setting owner

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

Re: [tor-bugs] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt refactoring dgoulet-  |  Actual Points:
  merge  |
Parent ID:  #29209   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  technical-debt refactoring => technical-debt refactoring
 dgoulet-merge


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

[tor-bugs] #30359 [Core Tor/Stem]: Stem PEP8 compliant

[Tor Bug Tracker & Wiki]

#30359: Stem PEP8 compliant
-+---
 Reporter:  0xrichard|  Owner:  atagar
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Component:  Core Tor/Stem
  Version:   |   Severity:  Minor
 Keywords:  dev  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
 Make the project PEP8 compliant.

 https://github.com/rj76/stem/pull/1

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

[tor-bugs] #30358 [Webpages/Blog]: Redirect season of docs blog link

[Tor Bug Tracker & Wiki]

#30358: Redirect season of docs blog link
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Redirect https://blog.torproject.org/google-season-docs-2019
 to https://blog.torproject.org/google-season-docs-2019-help-tor-improve-
 our-documentation

 Both links have been shared as the correct link.

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

Re: [tor-bugs] #29034 [Core Tor/Tor]: circuit: Cleanup an HS circuit when it is being re-purposed

[Tor Bug Tracker & Wiki]

#29034: circuit: Cleanup an HS circuit when it is being re-purposed
-+-
 Reporter:  dgoulet  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs-reachability, 029-backport-   |  Actual Points:
  maybe, 034-backport-maybe, 035-backport,   |
  040-backport, postfreeze-ok, network-team- |
  roadmap-2019-Q1Q2  |
Parent ID:  #29995   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * cc: dgoulet (added)


Comment:

 Hey David, what needs to happen here?

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

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

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28632   | Points:  8
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Replying to [comment:19 mikeperry]:
 > Some minor comments on the PR for the code and the spec.
 >

 Thanks for the review!

 > High level questions+comments:
 >
 > 1. Should we #define CIRCPAD_STATE_SPOOF_GENERAL CIRCPAD_STATE_BURST,
 and use a different terminology (and variables) for that first state? I
 think using the wtf-pad names can be confusing, since we're not using the
 histograms in the same way it did.

 I agree that the `BURST` and `GAP` state names are kinda random right now.
 There is also the question of how `circpad_state_to_string()` should work
 in case we rename them.

 Perhaps for these machines, we could have more specific names like
 `CIRCPAD_STATE_BURST` can become `CIRCPAD_STATE_OBFUSCATE_CIRC_SETUP`?
 `SPOOF_GENERAL` also seems like a decent generic name, but not sure what
 kind of machine would like that name, instead of defining their own.

 > 2. Should we flag these machines as reduced padding using #29203?

 Yes, that's a good question. Right now "reduced padding" is a very vague
 concept...

 Right now these machines are very low overhead at 15 padding cells in
 average, but perhaps we should not flag them as reduced padding until we
 learn what exactly reduced padding means by doing proper bandwidth
 overhead examinations.

 I'd like to do these examinations as part of my PhD research, so perhaps
 we can avoid markin them as such, and wait for the data? I don't think the
 world is gonna go crazy if we have to disable these machines in case we
 find that the bandwidth is too much.

 > 3. It's hard to follow force-pushed PRs like this. I personally would
 prefer a fresh PR squashed down rather than worrying about which version
 of the force-push I click on for a commit when doing the review.
 >

 Sorry about that. Will have that in mind for next time.

 > I can do the renaming of the burst state in the code and spec if we
 agree on a name for the first state of the intro and rend machines.

 Also replied to the comments on the PR.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30357 [- Select a component]: find out if HTTPSEverythwere language mapping should follow the changes done with torbutton

[Tor Bug Tracker & Wiki]

#30357: find out if HTTPSEverythwere language mapping should follow the changes
done with torbutton
-+-
 Reporter:  emmapeel |  Owner:  emmapeel
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  - Select a   |Version:
  component  |   Keywords:  localization,
 Severity:  Normal   |  httpseverywhere
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 in torbutton and soon in torlauncher we change some languages from
 transifex to get closer to Firefox-ESR locales.

 I should find out what is the desire of the HTTPSEverywhere team regarding
 this, and change their files as well.


 The changes are

 transifex lang bn = bn-BD
 transifex lang en_GB = en-GB
 transifex lang en = en-US
 transifex lang es_AR = es-AR
 transifex lang es_CL = es-CL
 transifex lang es_CO = es-CO
 transifex lang es = es-ES
 transifex lang es_MX = es-MX
 transifex lang fy = fy-NL
 transifex lang ga = ga-IE
 transifex lang gu = gu-IN
 transifex lang hi = hi-IN
 transifex lang hy = hy-AM
 transifex lang ms_MY = ms
 transifex lang nb = nb-NO
 transifex lang nn = nn-NO
 transifex lang nl_BE = nl-BE
 transifex lang pa = pa-IN
 transifex lang pt_BR = pt-BR
 transifex lang pt_PT = pt-PT
 transifex lang si_LK = si
 transifex lang sv = sv-SE
 transifex lang zh_CN = zh-CN
 transifex lang zh_HK = zh-HK
 transifex lang zh_TW = zh-TW

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

Re: [tor-bugs] #30054 [Community/Translations]: Special characters are not escaped in translations and break the build

[Tor Bug Tracker & Wiki]

#30054: Special characters are not escaped in translations and break the build
-+-
 Reporter:  gk   |  Owner:
 |  emmapeel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Community/Translations   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904,|  Actual Points:
  GeorgKoppen201904  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 I think it is important to have a CI test that ensures that the
 translations aren't breaking anything.  For F-Droid, I wrote an emulator
 test that loads all strings in all locales.  It has found many crasher
 bugs.  Feel free to take it under the license you need, it will need some
 tweaking to work in a different app (it is GPLv3+ in F-Droid):
 
https://gitlab.com/fdroid/fdroidclient/blob/master/app/src/androidTest/java/org/fdroid/fdroid/LocalizationTest.java

 IMHO, the translation tool should properly escape the translator's input
 whenever possible.  I believe Weblate does a pretty good job of this.
 Weblate checks are also quite useful for this kind of thing

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

Re: [tor-bugs] #30214 [Applications/Tor Browser]: TBA - NPE in ChangeOnionAlphaRunnable

[Tor Bug Tracker & Wiki]

#30214: TBA - NPE in ChangeOnionAlphaRunnable
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201905R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good to me. Let's see whether we are squashing #29982 here as well.
 Cherry-picked to `tor-browser-60.6.1esr-8.5-1` as commit
 7a0a10b8ff98ebfc53fa46fb3223af0f64a97964.

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

Re: [tor-bugs] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  6
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Replying to [comment:30 mikeperry]:
 > Can we back up and discuss the root reasons why you feel this approach
 risky? My read of the above is that your three concerns are: code clarity,
 memory leaks, and purpose changes. Is that right?
 >

 Yes, I think these are legitimate reasons to worry about. I think another
 worry is that because of overriding `mark_for_close()` we might get into a
 situation where the body of the function actually never gets called, and
 circuits stay alive for ever. I find this worry reasonable because
 `circpad_circuit_should_be_marked_for_close()` is a non-trivial function
 and we should make sure it does not permanently block a circuit from
 getting closed. Given that we have no functional machine right now,
 testing that this code works as intended in the real network is hard and
 hence this worry is even more reasonable.

 That said, I'm also not sure if Nick's suggested solution of using an
 intermediate function `circuit_transition_to_shutdown()` is good enough.
 As has been said, `mark_for_close()` is a function that is consumed all
 over the codebase and by every developer, and if we introduce our own
 intermediate function this means that all developers need to be aware of
 when the intermediate function should be used instead of
 `mark_for_close()`. I'm already having trouble thinking about where
 `mark_for_close()` should be replaced by `transition_to_shutdown()` in the
 current codebase, let alone having all developers keep this in mind for
 ever in the future. That's why I think having the circuitpadding subsystem
 keep track of this might make more sense, in a similar way that the
 pathbias subsystem uses `pathbias_check_close()` to track the same thing.

 

 Here is a **suggestion** of how to meet in the middle here. We keep the
 current logic, but we also add an assert-like function that checks whether
 the invariants here are preserved as we wish them to be. We can call that
 function from `assert_circuit_ok()` and also from
 `circuit_expire_old_circuits_clientside()` and we make sure that if
 something is going wrong it warns loud enough that we get bug reports and
 notice it quickly.

 Here is an example of a scenario that we should be checking: "If a circuit
 is alive and has a machine that manages its own lifetime, the machine
 should still be running, or if has ENDed and the circuit must have not
 expired yet.". Or, to catch errors that would let vanilla circuits never
 get marked for close, we could add an extra debug-field to a circuit that
 gets set in the beginning of `mark_for_close()` and we make sure that a
 circuit cannot linger around with that field if it does not have a machine
 that manages its own lifetime". These are just quick examples: to make
 good ones, we should think of the behavior we want from our circuits, and
 come up with the right invariants to preserve those behaviors.

 What do you say?

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

Re: [tor-bugs] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hm, seems like CI is broken because of at least
 `src/core/or/circuitpadding.c::1: error: no previous prototype for
 ‘circpad_is_padding_allowed’ [-Werror=missing-prototypes]` . Not sure
 if there are other errors too.

 I also let two other comments in the PR.

 After that, I think we are good to go.

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

Re: [tor-bugs] #30286 [Core Tor/Tor]: pre-push git hook will warn about fixups for no reason

[Tor Bug Tracker & Wiki]

#30286: pre-push git hook will warn about fixups for no reason
+
 Reporter:  asn |  Owner:  rl1987
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci git-scripts  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  |Sponsor:
+
Changes (by asn):

 * status:  needs_information => new


Comment:

 Replying to [comment:3 rl1987]:
 > Regarding "Github but not upstream" part, we can refrain from checking
 commit titles when not pushing to upstream. See:
 https://github.com/rl1987/tor/commit/d91d45c3433cc7dcaf1e67a84692420db870
 >
 > The second part is harder. To list commits that first appeared on branch
 being pushed one needs to find out parent branch, which seems to require
 some nasty looking code to make it work in general case. See:
 > * https://stackoverflow.com/a/4649377
 > * https://stackoverflow.com/questions/3161204/find-the-parent-branch-
 of-a-git-branch
 >
 > Not sure the extra complexity cost makes it worthwhile?

 I think we should at least do the `github but not upstream` part, because
 right now we can't push stuff without dirty workarounds.

 Not sure if the second part is worth doing indeed. Let's start with the
 first and see how it goes?

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

Re: [tor-bugs] #30342 [Core Tor/Tor]: 9 dephects on prob_distr.c (April 2019)

[Tor Bug Tracker & Wiki]

#30342: 9 dephects on prob_distr.c (April 2019)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prob-distr coverity  |  Actual Points:
Parent ID:   | Points:  0.4
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 Replying to [comment:3 catalyst]:
 > in src/lib/math/prob_distr.h:
 > {{{
 >  53  *  We define this conditionally to suppress false positives
 from
 >  54  *  Coverity, which gets confused by the sizeof business.
 >  55  */
 >  56 #ifdef __COVERITY___
 >  57 #define TYPE_CHECK_OBJ(OPS, OBJ, TYPE) 0
 > }}}
 > There seems to be an extra underscore at the end of `__COVERITY___`. I
 think all other occurrences end with two underscores, not three.

 Yes, you are right. Indeed, coverity seems to have a revision of the
 codebase with 3 underscores, but that's not the case in master (since
 `48a574604bef`):
 https://github.com/torproject/tor/blob/master/src/lib/math/prob_distr.h#L56

 CID `1444641` was also fixed in #30180 and yet it still appears in the web
 interface.

 Finally, wrt CID `1415723` (mentioned in the comment above), the CID does
 not appear in the web interface anymore (but i did receive it in an email
 on the 30th of April). The assert I was refering to is
 
https://github.com/torproject/tor/blob/master/src/feature/client/circpathbias.c#L189

 tl;dr coverity has a dated version of our codebase, and also sends emails
 about fixed issues. Not sure what we could do here, since I dont see a
 button that pulls the latest git rev.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30356 [Obfuscation/Snowflake]: Hello, this morning, in China, the connection to Tor network through Snowflake bridge was suddenly terminated.

[Tor Bug Tracker & Wiki]

#30356: Hello, this morning, in China, the connection to Tor network through
Snowflake bridge was suddenly terminated.
+---
 Reporter:  amiableclarity2011  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Component:  Obfuscation/Snowflake
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 Hello, this morning, in China, the connection to Tor network through
 Snowflake bridge was suddenly terminated. This morning, at first, I can
 connect to the Tor network through Snowflake bridge. But after a while,
 the connection to Tor network was suddenly terminated. It seems that
 China's firewall can automatically detect Snowflake proxies and block the
 Snowflake proxies that China's firewall just detected.

 Could you please solve this problem? Thank you very much for your help. I
 really appreciate it.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #28044, #30069, #26861, #27045, ...

[Tor Bug Tracker & Wiki]

Batch modification to #28044, #30069, #26861, #27045, #27265, #29045, #29187, 
#29307, #29319, #29627, #30136 by gk:


Comment:
No April anymore, moving review tickets to May.

--
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