Re: [tor-bugs] #32895 [Applications/Tor Browser]: Improve marsigning_check.sh script to deal better with non-reproducible, signed macOS mar files

[Tor Bug Tracker & Wiki]

#32895: Improve marsigning_check.sh script to deal better with non-reproducible,
signed macOS mar files
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sign, tbb-maint, |  Actual Points:
  GeorgKoppen202005, TorBrowserTeam202005R   |
Parent ID:   | Points:
 Reviewer:  sysrqb   |Sponsor:
-+-
Changes (by gk):

 * cc: tbb-team (added)
 * keywords:  tbb-sign, tbb-maint, GeorgKoppen202005 => tbb-sign, tbb-maint,
 GeorgKoppen202005, TorBrowserTeam202005R
 * status:  assigned => needs_review
 * reviewer:   => sysrqb


Comment:

 `bug_32895` () has a patch for review. I fixed all the issues `shellcheck`
 found, too, while I was at 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] #34231 [Metrics/Onionperf]: Document and maybe improve how we're mapping TGen transfers to Tor streams/circuits

[Tor Bug Tracker & Wiki]

#34231: Document and maybe improve how we're mapping TGen transfers to Tor
streams/circuits
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33328 | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by acute):

 At the moment, Onionperf uses `stem` to log events from the Tor control
 socket corresponding to Onionperf's tor process, and later parses these
 logs (we refer to them as `torctl` logs) line by line at analysis time
 into `CircuitEvents`, `StreamEvents`, `BandwidthEvents` and
 `BuildTimeoutSetEvents`.

 The `StreamEvent` is used to extract the port which originated the
 connection (source port) and circuit ID, which is what we currently use
 for matching. There don't seem to be any other useful `StreamEvent`
 variables that can help with matching (see
 https://stem.torproject.org/api/response.html).

 However, I believe we can match `tgen` streams to Tor circuits in the
 `torctl` logs directly using SOCKS authentication.

 `Tgen 1.0.0` supports generating random usernames and passwords for SOCKS
 authentication, which can be be used to uniquely identify a transfer and
 match it to a `CircuitEvent` (`stem` already fills the `socks_username`
 and `socks_password` fields during parsing anyway).

 I've done a quick test to check,  this is how the log lines look like if
 we enable the random SOCKS authentication strings in `tgen`:

 {{{
 2020-05-23 18:01:14 1590253274.675001 [info] [tgen-transport.c:771]
 [_tgentransport_receiveSocksAuth] socks server localhost:127.0.0.1:34810
 authentication succeeded with username='zRhBJ8o' and password='zRhBJ8o'
 }}}

 ...and this is a sample line from the corresponding `torctl` log:
 {{{
 2020-05-23 18:01:17 1590253277.57 650 CIRC 406 EXTENDED
 
$87C08DDFD32C62F3C56D371F9774D27BFDBB807B~Unnamed,$B9E7A637B00BBB77853A639CC33245A2FEB8F033~theykilledaaron,$3E13E2EB87CCF5690564EE33E9F9F9F80B229FBB~hotzenplotz
 BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_CLIENT_REND
 HS_STATE=HSCR_CONNECTING
 REND_QUERY=afa4fswz3ifwlbwsgk6va7vbbxj35m3geo3hvpc5u22w66yadr6xfayd
 TIME_CREATED=2020-05-23T17:01:16.357678 SOCKS_USERNAME="zRhBJ8o"
 SOCKS_PASSWORD="zRhBJ8o"
 }}}

 As far as the code goes, the change to the Onionperf parsers seems simple,
 and this is a better way of matching.

 Some questions/thoughts:

   * Turning on SOCKS authentication in Onionperf means we use stream
 isolation. My understanding is that each transfer (stream) would use a
 different circuit, which is what we expect anyway in Onionperf? Would this
 change affect measurements?

   * Is it likely that the `tgen` generated SOCKS credentials would
 conflict?

   * If we have plans to change what we use to parse Onionperf logs, we
 should check the replacements support this.

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

Re: [tor-bugs] #34286 [Applications/GetTor]: gettor appears to be in an email loop war with a .sk address

[Tor Bug Tracker & Wiki]

#34286: gettor appears to be in an email loop war with a .sk address
-+--
 Reporter:  arma |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+--
Changes (by cohosh):

 * status:  merge_ready => assigned


Comment:

 Okay I'm still getting the repeated requests so I looked at the emails in
 the database and found the following:

 {{{
 get...@torproject.org|links|windows|is|email|20200523142434|ONHOLD
 postmaster@[REDACTED].sk|links|windows|is|email|20200523142435|ONHOLD
 }}}

 So our list was incomplete :) Setting this back to assigned to add
 GetTor's own email and `postmaster@` emails to the list we won't respond
 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] #34286 [Applications/GetTor]: gettor appears to be in an email loop war with a .sk address

[Tor Bug Tracker & Wiki]

#34286: gettor appears to be in an email loop war with a .sk address
-+-
 Reporter:  arma |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+-

Comment (by cohosh):

 Replying to [comment:3 phw]:
 > Looks good to me!

 Thanks, merged and deployed at `2020-05-23T14:21:52+`.
 >
 > On a slightly related note: I believe that an email's body is supposed
 to be separated by two (rather than one) newlines from its header.
 GetTor's unit tests are using only one (and mix \n with \r\n). Python's
 email module is also confused by this and thinks that the body is part of
 the `To` field:

 Created #34300 for this, thanks!

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

[tor-bugs] #34300 [Applications/GetTor]: Ensure GetTor's email unit tests are properly formatted

[Tor Bug Tracker & Wiki]

#34300: Ensure GetTor's email unit tests are properly formatted
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 From #34286:

 [comment:3 phw]:
 > Looks good to me!
 >
 > On a slightly related note: I believe that an email's body is supposed
 to be separated by two (rather than one) newlines from its header.
 GetTor's unit tests are using only one (and mix \n with \r\n). Python's
 email module is also confused by this and thinks that the body is part of
 the `To` field:
 >
 > {{{
 > In [1]: from email import message_from_string
 > In [3]: m=message_from_string("From: MAILER-
 dae...@mx1.riseup.net\nSubject: Undelivered Mail Returned to Sender\r\nTo:
 get...@torproject.org\n osx en\n")
 > In [6]: m.items()
 > Out[6]:
 > [('From', 'mailer-dae...@mx1.riseup.net'),
 >  ('Subject', 'Undelivered Mail Returned to Sender'),
 >  ('To', 'get...@torproject.org\n osx en')]
 > }}}
 >
 > This seems like something we should fix.

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

Re: [tor-bugs] #32895 [Applications/Tor Browser]: Improve marsigning_check.sh script to deal better with non-reproducible, signed macOS mar files

[Tor Bug Tracker & Wiki]

#32895: Improve marsigning_check.sh script to deal better with non-reproducible,
signed macOS mar files
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sign, tbb-maint, |  Actual Points:
  GeorgKoppen202005  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => assigned
 * keywords:  tbb-sign => tbb-sign, tbb-maint, GeorgKoppen202005
 * owner:  tbb-team => gk


Old description:

> Our current mar-signing check script does two things:
>
> 1) It checks whether the SHA-256 sum from the signed .mar file is the
> same one as from the unsigned one and returns an error if so.
>
> 2) It strips the signature and compares the SHA-256 sum of the resulting
> .mar file with the unsigned one.
>
> Step 2) essentially tries to do 2 checks in one: a) that there is a
> proper signature that can get stripped and b) that the resulting .mar
> file is the same as the unsigned one. That's cool in theory as we want to
> have both checks but it has a number of issues in practice. The most
> important ones are:
>
> i) The script fails the mar-signing check for macOS as the stripping the
> signatures from those files does not give us the unsigned .mar due to the
> content signing
>
> ii) It's not clear we signed actually with the right key (although that
> is in practice not much of an issue) or whether the signature verifies
> later on (which is actually what we want to know).

New description:

 Our current mar-signing check script does two things:

 1) It checks whether the SHA-256 sum from the signed .mar file is the same
 one as from the unsigned one and returns an error if so.

 2) It strips the signature and compares the SHA-256 sum of the resulting
 .mar file with the unsigned one.

 Step 2) essentially tries to do 2 checks in one: a) that there is a proper
 signature that can get stripped and b) that the resulting .mar file is the
 same as the unsigned one. That's cool in theory as we want to have both
 checks but it has a number of issues in practice. The most important ones
 are:

 i) The script fails the mar-signing check for macOS as stripping the
 signatures from those files does not give us the unsigned .mar yet due to
 the content signing. (see: #20254)

 ii) It's not clear we signed actually with the right key (although that is
 in practice not much of an issue) or whether the signature verifies later
 on (which is actually what we want to know).

--

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

Re: [tor-bugs] #20254 [Applications/Quality Assurance and Testing]: Update marsigning-check.sh to cope with signed OS X MAR files

[Tor Bug Tracker & Wiki]

#20254: Update marsigning-check.sh to cope with signed OS X MAR files
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-sign,   |  Actual Points:
  GeorgKoppen201806, TorBrowserTeam201806,   |
  ReleaseTrainMigration  |
Parent ID:  #18925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-rbm, GeorgKoppen201806, TorBrowserTeam201806,
 ReleaseTrainMigration
 =>
 tbb-rbm, tbb-sign, GeorgKoppen201806, TorBrowserTeam201806,
 ReleaseTrainMigration
 * sponsor:  Sponsor58 =>


Comment:

 That's not S58 related.

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

Re: [tor-bugs] #34024 [Metrics/Onionperf]: Reduce timeout and stallout values

[Tor Bug Tracker & Wiki]

#34024: Reduce timeout and stallout values
---+
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:  0.1
Parent ID:  #33321 | Points:  1
 Reviewer:  acute  |Sponsor:  Sponsor59-must
---+
Changes (by acute):

 * status:  needs_review => merge_ready
 * reviewer:   => acute
 * actualpoints:   => 0.1


Comment:

 The commit looks good and the transfer behaviour is as expected.
 Adding 0.1 actual points and changing to merge_ready.

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

Re: [tor-bugs] #34298 [Metrics/Onionperf]: Address networkx's API change, which breaks OnionPerf

[Tor Bug Tracker & Wiki]

#34298: Address networkx's API change, which breaks OnionPerf
---+--
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 The patch looks good, but the current version of `python3-networkx` in
 Debian Stable (what we run in deployment) is 2.2.1, so this would break
 it.

 Maybe we could create a `debian-testing` branch where we could merge this
 patch/other bugs we find with newer library versions?

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

Re: [tor-bugs] #14149 [Core Tor/Tor]: Update spec with regards to 25-26 hours HSDir flag uptime that turned to 96 hours.

[Tor Bug Tracker & Wiki]

#14149: Update spec with regards to 25-26 hours HSDir flag uptime that turned 
to 96
hours.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * severity:  Blocker => Normal


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

Re: [tor-bugs] #14149 [Core Tor/Tor]: Update spec with regards to 25-26 hours HSDir flag uptime that turned to 96 hours.

[Tor Bug Tracker & Wiki]

#14149: Update spec with regards to 25-26 hours HSDir flag uptime that turned 
to 96
hours.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Blocker   | Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * severity:   => Blocker


Comment:

 (We missed the man page update here; I opened #34299 for that. Better late
 than never :)

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

Re: [tor-bugs] #34299 [Core Tor/Tor]: man page has wrong default for MinUptimeHidServDirectoryV2

[Tor Bug Tracker & Wiki]

#34299: man page has wrong default for MinUptimeHidServDirectoryV2
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> In #12485 (Tor 0.2.6.3-alpha) we changed the default for
> MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory
> authorities had already changed it manually. We changed the spec too. But
> we forgot to change the man page.

New description:

 In #14149 (Tor 0.2.6.3-alpha) we changed the default for
 MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory
 authorities had already changed it manually. We changed the spec too. But
 we forgot to change the man page.

--

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

Re: [tor-bugs] #34299 [Core Tor/Tor]: man page has wrong default for MinUptimeHidServDirectoryV2

[Tor Bug Tracker & Wiki]

#34299: man page has wrong default for MinUptimeHidServDirectoryV2
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 github says that my travis-ci failed. I don't think it failed because of
 my commit. But I don't know.

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

Re: [tor-bugs] #34299 [Core Tor/Tor]: man page has wrong default for MinUptimeHidServDirectoryV2

[Tor Bug Tracker & Wiki]

#34299: man page has wrong default for MinUptimeHidServDirectoryV2
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  new => needs_review
 * version:   => Tor: 0.2.6.3-alpha


Comment:

 My {{{bug34299}}} branch has a fix. It also rewords the man page sentence
 a bit. It is based on maint-0.4.3, but I would be fine if it gets merged
 only into 0.4.4.

 I believe I also posted the branch to my github armadev account, and
 created a github pull request:
 https://github.com/torproject/tor/pull/1905

 If we wanted, we could deprecate the "V2" part of the torrc name, since it
 is confusing that it secretly means "for all onion service designs after
 that one we replaced in 2007". Technically, maybe we could explain that it
 is v2 of the hsdir protocol, not v2 of onion services. But then again, the
 consensus says that we're on v1 of the hsdir protocol. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #34299 [Core Tor/Tor]: man page has wrong default for MinUptimeHidServDirectoryV2

[Tor Bug Tracker & Wiki]

#34299: man page has wrong default for MinUptimeHidServDirectoryV2
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #12485 (Tor 0.2.6.3-alpha) we changed the default for
 MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory
 authorities had already changed it manually. We changed the spec too. But
 we forgot to change the man page.

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

Re: [tor-bugs] #34263 [Circumvention/Snowflake]: Library selection for using WebRTC for the project.

[Tor Bug Tracker & Wiki]

#34263: Library selection for using WebRTC for the project.
-+
 Reporter:  HashikD  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-mobile |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by HashikD):

 Replying to [comment:6 arlolra]:
 > Sorry if this was covered elsewhere but is using pion, like the rest of
 the snowflake ecosystem, not an option?


 Hello, arlora. There is no pre-built library like Google's WebRTC for
 Android. If we want to use Pion we have to write a
 [https://developer.android.com/training/articles/perf-jni.html JNI
 Wrapper] ourselves. in the case of the above-said library, it's all
 already done and ready to use.

 More details on how to use Go libraries on Android:
 https://medium.com/@AndroidAdvance/running-go-from-android-ios-tutorial-
 7f1d456c5b0f
 http://www.codingvelocity.com/2015/08/08/go-bind-intro.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