date:20170715

[tor-bugs] #22946 [Applications/Tor Browser Sandbox]: Implement a MAR decompressor/delta updater.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22946: Implement a MAR decompressor/delta updater.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Long term, depending on `Browser/updater` to apply MAR files is probably a
 poor decision. regardless of the fact that it's being fed trusted input in
 a network-less container.

 So the sandbox should grow the ability to apply MAR files by itself.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22790 [Internal Services/Service - jenkins]: Stem jenkins tests unable to invoke tor

2017-07-15 Thread Tor Bug Tracker & Wiki

#22790: Stem jenkins tests unable to invoke tor
-+
 Reporter:  atagar   |  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by atagar):

 Great, thanks weasel!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22945 [Obfuscation/Snowflake]: End-to-end confidentiality for Snowflake client registrations

2017-07-15 Thread Tor Bug Tracker & Wiki

#22945: End-to-end confidentiality for Snowflake client registrations
---+-
 Reporter:  dcf|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Client requests sent to the /client broker endpoint use TLS to the front
 domain, and TLS from the front to the broker, but the fronting service
 itself (e.g. App Engine) can inspect them in plaintext. The fronting
 service unavoidably gets to learn the IP addresses of clients, but we
 could encrypt the additional metadata that appears in the registration
 messages.

 I was thinking of giving the broker a private key and wrapping client
 registrations in a [https://godoc.org/golang.org/x/crypto/nacl/box NaCl
 box].

 This is roughly how it worked in flash proxy. The facilitator had a
 private RSA key, and client registration methods were encrypted before
 being posted to the facilitator.
 
https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator.cgi?id=1.4#n60
 The actual key material was isolated into a facilitator-reg-daemon process
 that was separated from the web server and facilitator CGI:
   https://gitweb.torproject.org/flashproxy.git/tree/facilitator
 /facilitator-reg-daemon?id=1.4

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22790 [Internal Services/Service - jenkins]: Stem jenkins tests unable to invoke tor

2017-07-15 Thread Tor Bug Tracker & Wiki

#22790: Stem jenkins tests unable to invoke tor
-+
 Reporter:  atagar   |  Owner:  weasel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 The stem-tor-ci-base job built Tor on wheezy, while our test run on jessie
 or stretch.

 We install the tor Debian package to pull in all the required binaries for
 the tor from stem-tor-ci-base to run, but this was now no longer the right
 set.

 Changed the base job to build on stretch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22735 [Core Tor/Tor]: prop224: HS desc overlap period func uses absolute times instead of slots

2017-07-15 Thread Tor Bug Tracker & Wiki

#22735: prop224: HS desc overlap period func uses absolute times instead of 
slots
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  task | Status:  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-hs spec-conformance  |  Actual Points:
Parent ID:  #20657   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-
 |  can
-+-
Changes (by asn):

 * keywords:  prop224 prop224-extra tor-hs spec-conformance => prop224 tor-
 hs spec-conformance


Comment:

 Removing `prop224-extra`. This needs to happen since it really influences
 our testing abilities. We can't really accurately test our overlap logic
 if chutney needs 12 hours to go to overlap mode.

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

Re: [tor-bugs] #22735 [Core Tor/Tor]: prop224: HS desc overlap period func uses absolute times instead of slots

2017-07-15 Thread Tor Bug Tracker & Wiki

#22735: prop224: HS desc overlap period func uses absolute times instead of 
slots
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 prop224-extra tor-hs spec-   |  Actual Points:
  conformance|
Parent ID:  #20657   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * parent:   => #20657


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22865 [Obfuscation/meek]: Explicitly set Content-Length to zero when there is no data to send

2017-07-15 Thread Tor Bug Tracker & Wiki

#22865: Explicitly set Content-Length to zero when there is no data to send
--+--
 Reporter:  twim  |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 I've just done a test here locally, and meek-client compiled with `go1.8.3
 linux/amd64` sends `Content-Length: 0` even without the patch from this
 ticket. I inspected the traffic by running a socat shim on port 4000:
 {{{
 socat -v -v TCP-LISTEN:4000,fork,reuseaddr OPENSSL:xxx.appspot.com:443
 }}}
 Then I configured tor to connect through 127.0.0.1:4000
 {{{
 UseBridges 1
 ClientTransportPlugin meek exec ./meek-client --log meek-client.log
 Bridge meek 0.0.2.0:3 url=http://xxx.appspot.com/ front=127.0.0.1:4000
 }}}
 The socat output contains examples like this:
 {{{
 POST / HTTP/1.1\r
 Host: meek-reflect-test.appspot.com\r
 User-Agent: Go-http-client/1.1\r
 Content-Length: 0\r
 X-Session-Id: Mv2/KXfE3mE\r
 Accept-Encoding: gzip\r
 \r
 }}}
 Are you able to reproduce this? I don't see how the patch would cause it
 to behave any differently. And the documentation for
 [https://golang.org/pkg/net/http/#NewRequest http.NewRequest] says that a
 *bytes.Reader has special handling and sets the body to the magic value
 [https://golang.org/pkg/net/http/#pkg-variables NoBody] when the length of
 the Reader is 0:
 > If body is of type *bytes.Buffer, *bytes.Reader, or *strings.Reader, the
 returned request's ContentLength is set to its exact value (instead of
 -1), GetBody is populated (so 307 and 308 redirects can replay the body),
 and Body is set to NoBody if the ContentLength is 0.
 So I'm wondering if this patch is really needed? If so, can you give me
 complete reproduction instructions so that I can see the bug for myself?

 

 Replying to [comment:6 twim]:
 > Seems to be not a bug. This is now persistent behavior at Google
 AppEngine Flexible Environment. Most likely it was being upgraded at that
 moment. Standard Environment works as before (without inspection
 middleware).

 I'm confused now by your references to the flexible environment. I tried
 deploying reflect.go to the flexible environment by adding `env: flex` to
 app.yaml:
 {{{
 env: flex
 runtime: go
 api_version: go1
 automatic_scaling:
   max_idle_instances: 2
   min_pending_latency: 1000ms

 handlers:
 - url: /.*
   script: _go_app
   secure: always
 }}}
 However that caused `gcloud app deploy` to display an error message:
 {{{
 2017/07/15 13:04:04 failed analyzing meek/appengine: the root of your app
 needs to be package "main" (currently "reflect")
 }}}
 If I change the package name from `"reflect"` to `"main"`, I get another
 error:
 {{{
 2017/07/15 13:05:45 failed analyzing meek/appengine: cannot find package
 "appengine" in any of:
 ...
 }}}
 So it seems that reflect.go needs more extensive changes than just
 attachment:0001-Explicitly-set-Content-Length-to-zero-when-there-
 is-.patch in order to run in the flexible environment. Are you running
 something other than reflect.go on App Engine?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22944 [Applications/TorBirdy]: RSS: prevent fetching of channel icons (was: RSS:prevent fetching of RSS icons)

2017-07-15 Thread Tor Bug Tracker & Wiki

#22944: RSS: prevent fetching of channel icons
---+-
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |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

Re: [tor-bugs] #22886 [Applications/TorBirdy]: Can't edit font mail

2017-07-15 Thread Tor Bug Tracker & Wiki

#22886: Can't edit font mail
---+-
 Reporter:  peylight   |  Owner:  sukhbir
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by cypherpunks):

 * status:  new => closed
 * resolution:   => 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

[tor-bugs] #22944 [Applications/TorBirdy]: RSS:prevent fetching of RSS icons

2017-07-15 Thread Tor Bug Tracker & Wiki

#22944: RSS:prevent fetching of RSS icons
---+-
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 As mentioned in ticket:19031#comment:4 Thunderbird fetches at each start
 the icons of each rss channel, to prevent Thunderbird from fetching all
 RSS channel icons at start/simultaneously (as torbirdy prevents TB to
 fetch emails at start) I suggest torbirdy shouldn't fetch them at all.
 (fetching all icons at the same time might identify a user)

 ```browser.chrome.site_icons = false```

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22943 [Core Tor/Stem]: Add Travis CI configuration so that Github forks receive CI coverage

2017-07-15 Thread Tor Bug Tracker & Wiki

#22943: Add Travis CI configuration so that Github forks receive CI coverage
-+-
 Reporter:  patrickod|  Owner:  atagar
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  continuous-integration ci unit-  |  Actual Points:
  testing testing new-developers travis best-|
  practice   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi Patrick, Stem already has CI via Jenkins...

 https://jenkins.torproject.org/job/stem-tor-ci/

 They're broken at the moment but that's another story...

 https://trac.torproject.org/projects/tor/ticket/22790

 Folks indeed make GitHub forks to send me pull requests but I'm unsure why
 CI would be important to them. They pull from master, make their change,
 run tests, and send me a pull request. It's not a long-lived fork. If it
 is they'd certainly be welcome to add this to themselves.

 Is there something I'm missing?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22790 [Internal Services/Service - jenkins]: Stem jenkins tests unable to invoke tor

2017-07-15 Thread Tor Bug Tracker & Wiki

#22790: Stem jenkins tests unable to invoke tor
-+
 Reporter:  atagar   |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by atagar):

 Hi there, is there anything I can do to push this along? The jenkins tests
 have been failing for a couple weeks now and pretty sure I don't have the
 permissions to fix 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] #22943 [Core Tor/Stem]: Add Travis CI configuration so that Github forks receive CI coverage

2017-07-15 Thread Tor Bug Tracker & Wiki

#22943: Add Travis CI configuration so that Github forks receive CI coverage
-+-
 Reporter:   |  Owner:  atagar
  patrickod  |
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Stem   |   Keywords:  continuous-integration ci unit-
 Severity:  Normal   |  testing testing new-developers travis best-
 |  practice
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Similarly to #22636 we should add a Travis CI configuration with a
 comprehensive test matrix to the project root so that developers working
 on their own Github forks receive easy access to working CI setups.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22474 [Webpages/Website]: Add recent hires to Tor People webpage

2017-07-15 Thread Tor Bug Tracker & Wiki

#22474: Add recent hires to Tor People webpage
--+
 Reporter:  nickm |  Owner:  linda
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 I'll now be maintaining the people page and asking folks if they want to
 be on it when added to tor-internal@.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19360 [Webpages/Website]: FlashProxy is archived in the Trac, but we still seek volunteers

2017-07-15 Thread Tor Bug Tracker & Wiki

#19360: FlashProxy is archived in the Trac, but we still seek volunteers
--+
 Reporter:  irl   |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 Oops, sorry - website tickets generally aren't on my radar. Thanks for
 pointing this out. Removed 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] #10073 [Webpages/Website]: Update signature verification page

2017-07-15 Thread Tor Bug Tracker & Wiki

#10073: Update signature verification page
+---
 Reporter:  mttp|  Owner:  erinn
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  SponsorO, #website-content  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by atagar):

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


Comment:

 Merging with https://trac.torproject.org/projects/tor/ticket/3893

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22573 [Webpages/Website]: GPG-key fetch instructions are out of date on verifying signatures website

2017-07-15 Thread Tor Bug Tracker & Wiki

#22573: GPG-key fetch instructions are out of date on verifying signatures 
website
--+---
 Reporter:  gk|  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #10073| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

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


Comment:

 Merging with https://trac.torproject.org/projects/tor/ticket/3893

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #3893 [Webpages/Website]: Verifying-signatures needs some work

2017-07-15 Thread Tor Bug Tracker & Wiki

#3893: Verifying-signatures needs some work
--+--
 Reporter:  mikeperry |  Owner:  arma
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

 * severity:   => Normal


Comment:

 More discussion about this page is on
 https://trac.torproject.org/projects/tor/ticket/10073

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22941 [Core Tor/Tor]: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22941: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.
--+---
 Reporter:  JohnMilos |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 check #22921 maybe the same. in short: check your system date, zone, time.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

2017-07-15 Thread Tor Bug Tracker & Wiki

#22940: prop224: HS revision counter should persist after service reboot
+
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657  | Points:  1
 Reviewer:  |Sponsor:  SponsorR-can
+

Comment (by nickm):

 Attached is a very silly order-preserving encryption example based on the
 scheme I've seen attributed to Bebek 02.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

2017-07-15 Thread Tor Bug Tracker & Wiki

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Jigsaw52):

 Here's how to reproduce this bug:

 /etc/tor/torrc:

 {{{
 Sandbox 1
 %include /etc/tor/torrc.d/
 }}}

 Make sure /etc/tor/torrc.d/ exists.

 Run tor:

 {{{
 tor -f /etc/tor/torrc
 }}}

 Send a SIGHUP to the tor process to make it reload the configuration file:

 {{{
 kill -1 
 }}}

 I am working on a 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] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

2017-07-15 Thread Tor Bug Tracker & Wiki

#22940: prop224: HS revision counter should persist after service reboot
+
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657  | Points:  1
 Reviewer:  |Sponsor:  SponsorR-can
+

Comment (by nickm):

 If you decide to do B, it would be a good application for an order-
 preserving encryption, which is kinda fun.  I'll write up a short example.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22941 [Core Tor/Tor]: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22941: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.
--+---
 Reporter:  JohnMilos |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by JohnMilos):

 Windows 7 ; appVersion="7.0.2".

 Regards,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22921 [Core Tor/Tor]: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22921: Tor 0.3.0.9 and 0.3.1.4-alpha on FreeBSD: Failed to find node for hop 0 
of
our path. Discarding this circuit.
--+
 Reporter:  neel  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Critical  | Resolution:
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_information
 * keywords:   => 030-backport
 * milestone:   => Tor: 0.3.1.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22941 [Core Tor/Tor]: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22941: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.
--+---
 Reporter:  JohnMilos |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information
 * component:  - Select a component => Core Tor/Tor


Comment:

 Which version of Windows? Which version of Tor? Can you add any more
 details? 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] #22942 [Applications/Tor Browser]: minor tbb ui nit

2017-07-15 Thread Tor Bug Tracker & Wiki

#22942: minor tbb ui nit
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 the bottom of the help menu below the 'about tor browser' option is
 highlightable
 not really critical

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22941 [- Select a component]: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22941: Bootstrapped frozen at 85% : Failed to find node for hop 0 of our path.
--+-
 Reporter:  JohnMilos |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Hi all,
 since a tor update, i can't no longer connect to tor.
 Look at the log :

 15/07/2017 17:09:12.700 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 15/07/2017 17:09:12.700 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 15/07/2017 17:09:12.700 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 15/07/2017 17:09:12.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 15/07/2017 17:09:13.700 [NOTICE] Bootstrapped 80%: Connecting to the Tor
 network
 15/07/2017 17:09:13.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:14.000 [NOTICE] Bootstrapped 85%: Finishing handshake
 with first hop
 15/07/2017 17:09:14.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:15.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:16.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:17.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:18.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:19.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:20.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:21.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:22.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:23.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:24.700 [WARN] Failed to find node for hop 0 of our path.
 Discarding this circuit.
 15/07/2017 17:09:24.900 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 15/07/2017 17:09:24.900 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 15/07/2017 17:09:24.900 [NOTICE] Closing old Socks listener on
 127.0.0.1:9150
 15/07/2017 17:09:25.700 [NOTICE] Delaying directory fetches:
 DisableNetwork is set.

 I'm on Windows.
 Thanks for the help !

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

2017-07-15 Thread Tor Bug Tracker & Wiki

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---
Changes (by Vort):

 * status:  new => needs_review


Comment:

 I think this patch is ready for review.
 Questions:
 1. Is it is ok to compare `result >= 0` or it should be `result > 0`?
 2. Maybe non-encrypted connection requires `update_send_buffer_size` call
 too?
 3. What is the good description for the function? `Fix slow upload for
 Windows Vista and Windows 7 (bug #22798)` would be enough?
 4. Is this code compatible enough with C compilers?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

2017-07-15 Thread Tor Bug Tracker & Wiki

#22940: prop224: HS revision counter should persist after service reboot
+
 Reporter:  asn |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  #20657  | Points:  1
 Reviewer:  |Sponsor:  SponsorR-can
+
Description changed by asn:

Old description:

> We currently have the following logic in the HSDir-side when accepting an
> HS descriptor:
> {{{
> if (cache_entry->plaintext_data->revision_counter >=
> desc->plaintext_data->revision_counter) {
>   log_info(LD_REND, "Descriptor revision counter in our cache is "
> "greater or equal than the one we received. "
> "Rejecting!");
>   goto err;
> }
> }}}
>
> Unfortunately, while HSes keep track of the revision counter in memory,
> they never save it on disk, so if the service reboots the Hs will lose
> track of the rev counter and publish descriptors with small counters that
> will get rejected by the HSDir.
>
> We have brainstormed the following solutions for this:
> a) Save the latest rev counter in the state file in a form like this:
> `HidServRevCounter   
> b) Set the rev counter to a value like `rounddown(time(NULL))` so that
> the HS always generates correct rev counters even without saving them on
> state.
>
> However, wrt (b), since the quoted check above rejects equal rev counters
> the HS will have trouble uploading descriptors in the same hour. We could
> backport a fix that changes the check to 0.3.0 and then do this idea but
> that's kind of a PITA.
>
> We are currently aiming for (a)

New description:

 We currently have the following logic in the HSDir-side when accepting an
 HS descriptor:
 {{{
 if (cache_entry->plaintext_data->revision_counter >=
 desc->plaintext_data->revision_counter) {
   log_info(LD_REND, "Descriptor revision counter in our cache is "
 "greater or equal than the one we received. "
 "Rejecting!");
   goto err;
 }
 }}}

 Unfortunately, while HSes keep track of the revision counter in memory,
 they never save it on disk, so if the service reboots the Hs will lose
 track of the rev counter and publish descriptors with small counters that
 will get rejected by the HSDir.

 We have brainstormed the following solutions for this:
 a) Save the latest rev counter in the state file in a form like this:
 `HidServRevCounter   `
 b) Set the rev counter to a value like `rounddown(time(NULL))` so that the
 HS always generates correct rev counters even without saving them on
 state.

 However, wrt (b), since the quoted check above rejects equal rev counters
 the HS will have trouble uploading descriptors in the same hour. We could
 backport a fix that changes the check to 0.3.0 and then do this idea but
 that's kind of a PITA.

 We are currently aiming for (a)

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22940 [Core Tor/Tor]: prop224: HS revision counter should persist after service reboot

2017-07-15 Thread Tor Bug Tracker & Wiki

#22940: prop224: HS revision counter should persist after service reboot
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs prop224
Actual Points:|  Parent ID:  #20657
   Points:  1 |   Reviewer:
  Sponsor:  SponsorR-can  |
--+
 We currently have the following logic in the HSDir-side when accepting an
 HS descriptor:
 {{{
 if (cache_entry->plaintext_data->revision_counter >=
 desc->plaintext_data->revision_counter) {
   log_info(LD_REND, "Descriptor revision counter in our cache is "
 "greater or equal than the one we received. "
 "Rejecting!");
   goto err;
 }
 }}}

 Unfortunately, while HSes keep track of the revision counter in memory,
 they never save it on disk, so if the service reboots the Hs will lose
 track of the rev counter and publish descriptors with small counters that
 will get rejected by the HSDir.

 We have brainstormed the following solutions for this:
 a) Save the latest rev counter in the state file in a form like this:
 `HidServRevCounter   
 b) Set the rev counter to a value like `rounddown(time(NULL))` so that the
 HS always generates correct rev counters even without saving them on
 state.

 However, wrt (b), since the quoted check above rejects equal rev counters
 the HS will have trouble uploading descriptors in the same hour. We could
 backport a fix that changes the check to 0.3.0 and then do this idea but
 that's kind of a PITA.

 We are currently aiming for (a)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22939 [Applications/Tor Messenger]: Can't configure my OTR key

2017-07-15 Thread Tor Bug Tracker & Wiki

#22939: Can't configure my OTR key
+-
 Reporter:  cypherpunks |  Owner:
 Type:  task| Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 1. Launch Tor Messenger.
 2. Connect to Tor Network.
 3. Open Add-ons and disable "Tor Launcher".
 4. Go to settings and set network proxy to my tor server(e.g.,
 localhost:9050)[1]

 5. Now, add XMPP account to it.
 6. Restart the client.
 7. I can connect to XMPP server.

 8. Open add-ons, Extensions, and click "Options" (ctypes-otr).


 Expected result:
 I can set my private keys, etc.

 Actual result:
 My Private keys
 No Accounts configured < WTF!?

 OTR settings
 [X] Require encryption
 [X] Always nudge




 [1] I'm using Tor Browser with TorLauncher/TorButton disabled. I set it to
 use my own tor socks proxy.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22938 [Internal Services/Tor Sysadmin Team]: Please refresh key - 0xCB8FC772D1AA1D30

2017-07-15 Thread Tor Bug Tracker & Wiki

#22938: Please refresh key - 0xCB8FC772D1AA1D30
-+-
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi,

 Please refresh key 0xCB8FC772D1AA1D30. New subkeys were added and the
 primary key's expiration date was extended.

 {{{
 amnesia@amnesia:~$ gpg -k 0xCB8FC772D1AA1D30
 gpg: key 0x1F6472DF4F8340C8 was created 555857 seconds in the future (time
 warp or clock problem)
 pub   4096R/0xCB8FC772D1AA1D30 2014-06-26 [expires: 2018-07-21]
   Key fingerprint = CE17 8262 4600 EE98 764C  6D9C CB8F C772 D1AA 1D30
 uid [ unknown] Matthew Finkel 
 uid [ unknown] Matthew Finkel 
 sub   4096R/0xE41A237D708F69E0 2017-07-14 [expires: 2018-01-10]
 sub   4096R/0x71885AE6EDBB9DCE 2017-07-14 [expires: 2018-01-10]
 sub   4096R/0xD867AC8FFDF86BEB 2017-07-14 [expires: 2018-01-10]
 }}}

 p.s. There are some (now revoked) subkeys cross-signed on this key that
 were created in the future. Sorry for any time warp warnings you receive.
 They'll disappear after 21 July.

 Many 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] #22937 [Core Tor/Tor]: Clarify how resolved values are encoded in cells

2017-07-15 Thread Tor Bug Tracker & Wiki

#22937: Clarify how resolved values are encoded in cells
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec easy doc
Actual Points:|  Parent ID:  #18856
   Points:|   Reviewer:
  Sponsor:|
--+
 T1. Is length 0 for error types?
 T2. IPv4 and IPv6 addresses are in network byte order
 T3. Hostnames are in standard DNS order (we might not need to say this)
 T4. TTLs are left out in NETINFO cells

 {{{
To find the address associated with a hostname, the OP sends a
RELAY_RESOLVE cell containing the hostname to be resolved with a NUL
terminating byte. (For a reverse lookup, the OP sends a RELAY_RESOLVE
cell containing an in-addr.arpa address.) The OR replies with a
RELAY_RESOLVED cell containing any number of answers. Each answer is
of the form:

Type   (1 octet)
Length (1 octet)
Value  (variable-width)
TTL(4 octets)
"Length" is the length of the Value field.
"Type" is one of:
   0x00 -- Hostname
   0x04 -- IPv4 address
   0x06 -- IPv6 address
   0xF0 -- Error, transient
   0xF1 -- Error, nontransient

 If any answer has a type of 'Error', then no other answer may be
 given.

 For backward compatibility, if there are any IPv4 answers, one of
 those
 must be given as the first answer.

 The RELAY_RESOLVE cell must use a nonzero, distinct streamID; the
 corresponding RELAY_RESOLVED cell must use the same streamID.  No
 stream
 is actually created by the OR when resolving the name.
 }}}

 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1480

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22936 [Core Tor/Tor]: Apply Windows Tor build patch for VS2015

2017-07-15 Thread Tor Bug Tracker & Wiki

#22936: Apply Windows Tor build patch for VS2015
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  windows build
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There's a patch for building Tor in Visual Studio 2015 at:
 https://github.com/wbenny/vs-
 tor/blob/master/vs2015/tor/tor_win32_patch.diff

 We should work out if we can apply it (there's no licence), or if we can
 learn useful things from it to improve our Windows support.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13410 [Applications/Tor Browser]: Disable self-signed certificate warnings when visiting .onion sites

2017-07-15 Thread Tor Bug Tracker & Wiki

#13410: Disable self-signed certificate warnings when visiting .onion sites
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  #ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 .onion is secure.
 == connection tranport is secure
 == HTTPS is secure!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22935: Disable SSL alert when visiting .onion HTTPS.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by cypherpunks):

 https://trac.torproject.org/projects/tor/ticket/13410

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13410 [Applications/Tor Browser]: Disable self-signed certificate warnings when visiting .onion sites

2017-07-15 Thread Tor Bug Tracker & Wiki

#13410: Disable self-signed certificate warnings when visiting .onion sites
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  #ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * priority:  Medium => Very High


Comment:

 https://trac.torproject.org/projects/tor/ticket/22935

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

2017-07-15 Thread Tor Bug Tracker & Wiki

#22935: Disable SSL alert when visiting .onion HTTPS.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 "We are not sure that the connection is secure" < something like this
 message.

 Can't you just add an option to disable HTTPS warnings while FQDN is
 .onion?
 I'm using self-signed certificate for proprietary server on .onion.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22934 [Core Tor/Tor]: PADDING cells can't be sent immediately after a VERSIONS cell

2017-07-15 Thread Tor Bug Tracker & Wiki

#22934: PADDING cells can't be sent immediately after a VERSIONS cell
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-relay  |  Actual Points:
Parent ID:  #18856   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 It appears that the channel state isn't updated until the read completes.
 If a send no or one VPADDING cell between VERSIONS and PADDING, the
 connection is closed.
 If a send 1000, the connection completes.

 For a script that demonstrates this, see:
 https://github.com/teor2345/endosome/blob/master/client-or-22934.py

 I think we should fix this by changing the channel state immediately after
 the VERSIONS cell is read, rather than after all the cells in the buffer
 are processed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22929 [Core Tor/Tor]: What cells can be sent before a VERSIONS cell, and what is their CIRCID_LEN?

2017-07-15 Thread Tor Bug Tracker & Wiki

#22929: What cells can be sent before a VERSIONS cell, and what is their
CIRCID_LEN?
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [ticket:22929 teor]:
 > tor-spec.txt says:
 > {{{
 >CIRCID_LEN is 2 for link protocol versions 1, 2, and 3.  CIRCID_LEN
 >is 4 for link protocol version 4 or higher.  The VERSIONS cell itself
 >always has CIRCID_LEN == 2 for backward compatibility.
 > }}}

 T1. This isn't strictly true: relays parse and drop duplicate VERSIONS
 cells, as long as those versions cells are formatted according to the
 *current* link version. In particular, relays will parse VERSIONS cells
 with CIRCID_LEN == 4 when link protocol 4 has been negotiated.
 See #22931 for details.

 > But what is the CIRCID_LEN for early VPADDING, AUTHORIZE, or PADDING
 cells?

 T2. PADDING cells are not allowed as the first cell, relays say:

 `[info] channel_tls_handle_cell: Received unexpected cell command 0 in
 chan state opening / conn state waiting for renegotiation or V3 handshake;
 closing the connection.`

 VPADDING cells are ignored, and the connection proceeds as normal.
 It's possible to send any number of VPADDING cells.

 > {{{
 >When this handshake is in use, the first cell must
 >be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed
 to
 >intervene besides those specified, except for PADDING and VPADDING
 cells.
 > }}}
 >
 > Is it valid to send VPADDING, then PADDING, then VERSIONS?

 T2. PADDING cells are not allowed before the VERSIONS cell, relays say:

 `[info] channel_tls_handle_cell: Received unexpected cell command 0 in
 chan state opening / conn state waiting for renegotiation or V3 handshake;
 closing the connection.`

 T3. In fact, PADDING cells don't seem to work after the VERSIONS cell,
 either. See #22934.

 > If so, what is their CIRCID_LEN?

 T4. Before the first VERSIONS cell, 2. Afterwards, whatever was
 negotiated.

 > Which sentence prevails, the one above, or the one below?
 >
 > {{{
 >Parties MUST NOT send any
 >other cells on a connection until they have received a VERSIONS cell.
 > }}}

 T5. VPADDING works fine.

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

[tor-bugs] #22934 [Core Tor/Tor]: PADDING cells can't be sent immediately after a VERSIONS cell

2017-07-15 Thread Tor Bug Tracker & Wiki

#22934: PADDING cells can't be sent immediately after a VERSIONS cell
--+-
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec, tor-relay
Actual Points:|  Parent ID:  #18856
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+-
 When I send a VERSIONS cell and a PADDING cell in the same socket write,
 Tor 0.3.0.9 closes the connection:
 {{{
 Jul 15 19:55:43.000 [info] channel_register: Channel 0x7f848276e300
 (global ID 207) in state opening (1) registered with no identity digest
 Jul 15 19:55:43.000 [info] channel_tls_process_versions_cell: Negotiated
 version 3 with [scrubbed]:58001; Sending cells: VERSIONS CERTS
 AUTH_CHALLENGE NETINFO
 Jul 15 19:55:43.000 [info] channel_tls_handle_cell: Received unexpected
 cell command 0 in chan state opening / conn state handshaking (Tor, v3
 handshake); closing the connection.
 Jul 15 19:55:43.000 [info] conn_close_if_marked: Conn (addr [scrubbed], fd
 9, type OR, state 7) marked, but wants to flush 2033 bytes. (Marked at
 src/or/connection_or.c:1338)
 Jul 15 19:55:43.000 [info] conn_close_if_marked: We stalled too much while
 trying to write 2033 bytes to address [scrubbed].  If this happens a lot,
 either something is wrong with your network connection, or something is
 wrong with theirs. (fd 9, type OR, state 7, marked at
 src/or/connection_or.c:1338).
 }}}
 It doesn't matter if I send a VPADDING cell before the padding cell.

 But the tor spec says:
 {{{
 When this handshake is in use, the first cell must
be VERSIONS, VPADDING or AUTHORIZE, and no other cell type is allowed
 to
intervene besides those specified, except for PADDING and VPADDING
 cells.
 }}}
 https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n482

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

2017-07-15 Thread Tor Bug Tracker & Wiki

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 New iteration of the patch: attachment:tor_windows_upload_fix_v2.patch
 * I have found better place for `update_send_buffer_size` function.
 * Version check was 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] #22931 [Core Tor/Tor]: What happens when a VERSIONS cell is sent outside a handshake?

2017-07-15 Thread Tor Bug Tracker & Wiki

#22931: What happens when a VERSIONS cell is sent outside a handshake?
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  new => needs_review


Comment:

 The relay drops extra versions cells. We could document this by saying:
 {{{
 + Any VERSIONS cells sent after the first VERSIONS cell MUST be ignored.
 }}}
 Changing versions on a link shouldn't be allowed.

 There are 3 possible cases:

 First and second version cells ask for link version 3 and has cird_id_len
 2:

 `Jul 15 18:41:01.000 [info] channel_tls_process_versions_cell: Received a
 VERSIONS cell on a connection with its version already set to 3; dropping`

 First version cell asks for link version 4 and has cird_id_len 2, second
 version cell asks for link version 4 and has cird_id_len 4:

 `Jul 15 18:46:14.000 [info] channel_tls_process_versions_cell: Received a
 VERSIONS cell on a connection with its version already set to 4; dropping`

 First version cell asks for link version 4 and has cird_id_len 2, second
 version cell asks for link version 4 and has cird_id_len 2:

 (The cell is mis-parsed: the command is read from the second byte of the
 versions cell's payload length. Since no further input arrives to complete
 the cell, the relay times out.)

 A script that sends cells to trigger all these cases is at:

 https://github.com/teor2345/endosome/blob/master/client-or-22931.py

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

2017-07-15 Thread Tor Bug Tracker & Wiki

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 > What will happens for win x128 or some another specific case

 I guess they will not change it:
 [[https://msdn.microsoft.com/en-
 us/library/windows/desktop/aa383751(v=vs.85).aspx|An unsigned LONG. The
 range is 0 through 4294967295 decimal]].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

2017-07-15 Thread Tor Bug Tracker & Wiki

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 > Here is my attempt to fix this problem

 SO_SNDBUF accept int, while SIO_IDEAL_SEND_BACKLOG_QUERY returns ULONG, no
 difference if sizeof(int)==sizeof(long). What will happens for win x128 or
 some another specific case, can setsockopt parse such input correctly?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22848 [Core Tor/Tor]: Increase default Tor buffer sizes on Windows

2017-07-15 Thread Tor Bug Tracker & Wiki

#22848: Increase default Tor buffer sizes on Windows
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows, performance tor-relay   |  Actual Points:
  win32  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by Vort):

 Solution, which uses "[[ticket:22798#comment:60|ideal send backlog]]", is
 more promising.
 For example, it is hard to get Guard flag with static 0.25 MiB buffer.
 It is small for such task. But for low latency connections, 0.25 MiB
 buffer will be an overkill.

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

46 matches

Mail list logo