date:20190207

Re: [tor-bugs] #29431 [Core Tor/Nyx]: nyx tool not working

2019-02-07 Thread Tor Bug Tracker & Wiki

#29431: nyx tool not working
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: unspecified
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * owner:  (none) => atagar
 * keywords:  nyx =>
 * component:  Applications => Core Tor/Nyx


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

Re: [tor-bugs] #29408 [Internal Services/Tor Sysadmin Team]: Can we move TB downloads to CDN?

2019-02-07 Thread Tor Bug Tracker & Wiki

#29408: Can we move TB downloads to CDN?
-+-
 Reporter:  ln5  |  Owner:  ln5
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: gk (added)


Comment:

 I don't know Fastly but what made me reluctant so far is that the risk of
 getting malware delivered in "official" Tor Browser binaries seems
 slightly higher if we are out of control here, given that we don't have
 content signing available for all platforms and who is checking signatures
 anyway. While this risk might seem not pretty strong, given that chances
 are not so bad that this will get detected, the potential damage in trust
 for us is pretty high, even if it turns out that was due to Fastly getting
 some NSLs and not "done" by us.

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

Re: [tor-bugs] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

2019-02-07 Thread Tor Bug Tracker & Wiki

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by dcf):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:8 ahf]:
 > Let's do this as an extension and keep `goptlib` for the low level
 details. `goptlibext` could be the name.

 I definitely want a basic `Log` function in goptlib itself. A higher-level
 interface, using `log.Logger` for example, is a good candidate for a
 separate library that builds on goptlib, I agree.

 Here's an implementation of `Log` along the lines of what I was thinking.
 The [attachment:0001-Bug-28940-add-support-for-LOG.patch full patch]
 includes more documentation and tests.
 {{{
 // Severity levels for the Log function.
 const (
 LogLevelError   = "error"
 LogLevelWarning = "warning"
 LogLevelNotice  = "notice"
 LogLevelInfo= "info"
 LogLevelDebug   = "debug"
 )

 // Encode a string according to the CString rules of section 2.1.1 in
 // control-spec.txt.
 //
 // We additionally need to ensure that whatever we return passes
 argIsSafe,
 // because strings encoded by this function are printed verbatim by Log.
 func encodeCString(s string) string {
 result := bytes.NewBuffer([]byte{})
 result.WriteByte('"')
 for _, c := range []byte(s) {
 if c == 32 || c == 33 || (35 <= c && c <= 91) || (93 <= c
 && c <= 126) {
 result.WriteByte(c)
 } else {
 fmt.Fprintf(result, "\\%03o", c)
 }
 }
 result.WriteByte('"')
 return result.String()
 }

 // Emit a LOG message with the given severity (one of LogLevelError,
 // LogLevelWarning, LogLevelNotice, LogLevelInfo, or LogLevelDebug).
 func Log(severity, message string) {
 // " contains the log message which can be a String or
 CString..."
 // encodeCString always makes the string safe to emit; i.e., it
 // satisfies argIsSafe.
 line("LOG", "SEVERITY="+encodeCString(severity),
 "MESSAGE="+encodeCString(message))
 }
 }}}

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

Re: [tor-bugs] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

2019-02-07 Thread Tor Bug Tracker & Wiki

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by dcf):

 * Attachment "0001-Bug-28940-add-support-for-LOG.patch" added.


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

Re: [tor-bugs] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

2019-02-07 Thread Tor Bug Tracker & Wiki

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by dcf):

 * Attachment "0001-Bug-28940-add-support-for-LOG.patch" removed.


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

Re: [tor-bugs] #28940 [Obfuscation/Pluggable transport]: Add support for LOG to goptlib

2019-02-07 Thread Tor Bug Tracker & Wiki

#28940: Add support for LOG to goptlib
-+-
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:  Sponsor19
-+-
Changes (by dcf):

 * Attachment "0001-Bug-28940-add-support-for-LOG.patch" added.


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

[tor-bugs] #29432 [Core Tor/Tor]: QuotedString and CString in control-spec.txt technically require escaping ascii 32 (space)

2019-02-07 Thread Tor Bug Tracker & Wiki

#29432: QuotedString and CString in control-spec.txt technically require 
escaping
ascii 32 (space)
--+--
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 control-spec.txt 2.1 [https://gitweb.torproject.org/torspec.git/tree
 /control-spec.txt?id=795420240305a6d67c0f4322993a65da4c7b6f2f#n110 says]:
 > === 2.1. Description format ===
 > We use the following nonterminals from RFC 2822: `atom`, `qcontent`
 > ...
 > {{{QuotedString = DQUOTE *qcontent DQUOTE}}}
 > ...
 > === 2.1.1. Notes on an escaping bug ===
 > {{{CString = DQUOTE *qcontent DQUOTE}}}

 RFC 2822 [https://tools.ietf.org/html/rfc2822#section-3.2.5 defines]
 `qcontent` thus:
 {{{
 qtext   =   NO-WS-CTL / ; Non white space controls

 %d33 /  ; The rest of the US-ASCII
 %d35-91 /   ;  characters not including "\"
 %d93-126;  or the quote character

 qcontent=   qtext / quoted-pair
 }}}
 where `NO-WS-CTL` [https://tools.ietf.org/html/rfc2822#section-3.2.1
 expands to]
 {{{
 NO-WS-CTL   =   %d1-8 / ; US-ASCII control characters
 %d11 /  ;  that do not include the
 %d12 /  ;  carriage return, line feed,
 %d14-31 /   ;  and white space characters
 %d127
 }}}

 In short, `qcontent` does not include the space character (ascii 32), and
 so according to a strict reading of the spec, anything that produces a
 QuotedString or CString has to escape spaces as `\ ` or `\040`.

 The reason why RFC 2822 does not require space to be escaped is that the
 definition of `quoted-string` is not `DQUOTE *qcontent DQUOTE` as in
 control-spec.txt, but also allows whitespace as part of the `[FWS]`
 production:
 {{{
 quoted-string   =   [CFWS]
 DQUOTE *([FWS] qcontent) [FWS] DQUOTE
 [CFWS]
 }}}

 I notice that tor doesn't escape the space character (in `esc_for_log` and
 `unescape_string` for example). IMO tor is doing the right, expected thing
 and the spec should be clarified.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29431 [Applications]: nyx tool not working

2019-02-07 Thread Tor Bug Tracker & Wiki

#29431: nyx tool not working
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications
  Version:  Tor: unspecified  |   Severity:  Major
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 There is a file not found error, see below
 Traceback (most recent call last):
 File "/usr/bin/nyx", line 11, in 
 load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 480,
 in load_entry_point
 return get_distribution(dist).load_entry_point(group, name)
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
 2693, in load_entry_point
 return ep.load()
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
 2324, in load
 return self.resolve()
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
 2330, in resolve
 module = __import__(self.module_name, fromlist=['__name__'], level=0)
 File "/usr/lib/python3/dist-packages/nyx/__init__.py", line 46, in
 import distutils.spawn
 ModuleNotFoundError: No module named 'distutils.spawn'

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

Re: [tor-bugs] #29308 [Obfuscation/Snowflake]: Remove Appspot-facing proxy-go instances

2019-02-07 Thread Tor Bug Tracker & Wiki

#29308: Remove Appspot-facing proxy-go instances
---+
 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:  cohosh |Sponsor:
---+

Comment (by dcf):

 I deleted the 3 instances at about 2019-02-07 23:45:00 and
 
[https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline?action=diff&version=310
 noted the change] at MetricsTimeline. This is what I did:
 {{{
 sv stop snowflake-proxy-{17h,23h,29h}
 rm -vr /etc/service/snowflake-proxy-{17h,23h,29h} /etc/runit/snowflake-
 proxy-{17h,23h,29h}
 etckeeper commit
 }}}

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

Re: [tor-bugs] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

2019-02-07 Thread Tor Bug Tracker & Wiki

#29430: Use uTLS for meek TLS camouflage in Tor Browser
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek utls |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "meek-client-utls_2.pcap" 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] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

2019-02-07 Thread Tor Bug Tracker & Wiki

Comment (by dcf):

Here is a sample branch that uses the same meek repo.
* [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h
=meek-client-utls_2&id=616fbe2c19a9fce7a9d0adbc466b259c18c45fb8 meek-
client-utls_2 branch]
* [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/diff/?h
=meek-client-

utls_2&id=616fbe2c19a9fce7a9d0adbc466b259c18c45fb8&id2=86ebdafc28a55042fea553ad7f23f796ea963b75
cumulative diff]

It's pretty straightforward; I think the noteworthy changes are:
* It only activates uTLS on alpha. I feel this is the kind of thing that
should be tested on alpha before going into stable.
* meek-client uses the mainline utls repo, not the fork that obfs4proxy
uses, so I moved the goutls project to goutls-yawning and re-added a
goutls project pointing to the original repo. I'm not sure what's best to
do here :/
* It requires a small tor-launcher patch: attachment:0001-Make-uTLS-
aware.patch, which I didn't upload to a branch anywhere.

There are a few additional changes that could happen, namely deleting the
meek-client-torbrowser executable and the meek-http-helper browser
profile.

It works; I'm using it to post this comment. I ran a [attachment:meek-
client-utls_2.pcap packet capture] of me using Moat and then starting to
bootstrap using meek-azure. There are 5 Client Hellos in the packet
capture, all with TLS fingerprint
[https://tlsfingerprint.io/id/71a81bafd58e1301 71a81bafd58e1301], which
uTLS calls `HelloIOS_11_1`. The first 4 are me struggling with the Moat
captcha (lol) and the 5th is starting the bootstrap itself.

I'm not marking this needs_review because I'm not necessarily proposing
this branch for merge, just using it as an example of what integration
could look like. I don't want to exclude the possibility of using
obfs4proxy. I think it's more like needs_discussion at this point.

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

1 2 >

1 - 100 of 175 matches

Mail list logo