Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  nickm |Sponsor:
--+

Comment (by isis):

 Replying to [comment:18 nickm]:
 > Hm, you meant in the torrc too though?  For that, usability does matter,
 though I may be forgetting the lesson of the bikeshed.

 Yes, I meant in the torrc too, mostly under the assumption that most
 people that most bridge operators won't need to touch it. I'm no UX expert
 though, so I can default to whatever the results of the bikeshed were.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 Replying to [comment:1 arma]:
 > Apparently the same issue affects https://www.torproject.org/docs/tor-
 relay-debian :
 > https://lists.torproject.org/pipermail/tor-relays/2017-March/012116.html

 No, that post is saying they went to that page, and followed the link to
 https://www.torproject.org/docs/debian.html.en where the problem appeared.
 The tor-relay-debian page itself was and is 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] #21775 [- Select a component]: Doesnt work on Windows 10 build 15061

[Tor Bug Tracker & Wiki]

#21775: Doesnt work on Windows 10 build 15061
--+-
 Reporter:  gilles.ienne@…|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 'Tor crash at opening with nothing in the log.'

 Can you help?

 Thanks

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

Re: [tor-bugs] #21774 [Core Tor/Stem]: Fix CONN_BW event listening

[Tor Bug Tracker & Wiki]

#21774: Fix CONN_BW event listening
---+
 Reporter:  timonh |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Great, thanks timonh for the pull request! I'm traveling until the 26th
 during which I can't merge anything, but change looks great and I'll pull
 it in when I get back.

 Thanks for the patch!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21753 [Applications/Tor Browser]: Get rid of old GCC toolchain in pluggable transports macOS descriptor

[Tor Bug Tracker & Wiki]

#21753: Get rid of old GCC toolchain in pluggable transports macOS descriptor
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam21703R,|  Actual Points:
  GeorgKoppen201703, tbb-gitian  |
Parent ID:  #21328   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:5 gk]:
 > Yeah, the stable target does seldom work on `master`, we have usually
 the `maint-` branches for that. Doing nightly builds is busted right now
 due to #21748 and PTs aren't working in nightly builds either (#21757).
 Thus, your best bet is probably using `make prep-alpha` and doing an alpha
 build and test that one.

 I see. I may not be able to test this soon, then. I haven't been able to
 build new base VM images on Debian for a while now. I think it is still
 this old issue: https://lists.torproject.org/pipermail/tbb-
 dev/2016-April/000371.html. I will have to apply the workaround of
 building new base VM images on Ubuntu and copying them to Debian, and I
 don't have an Ubuntu set up right now.

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

Re: [tor-bugs] #21753 [Applications/Tor Browser]: Get rid of old GCC toolchain in pluggable transports macOS descriptor

[Tor Bug Tracker & Wiki]

#21753: Get rid of old GCC toolchain in pluggable transports macOS descriptor
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam21703R,|  Actual Points:
  GeorgKoppen201703, tbb-gitian  |
Parent ID:  #21328   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 dcf]:
 > However, `make prep` is failing for me on the `bug_21753_v3` branch:
 > {{{
 > --2017-03-19 12:37:08--
 https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/45.2.0esr-
 candidates/build2/linux-i686/xpi/ar.xpi
 > Resolving ftp.mozilla.org (ftp.mozilla.org)... 54.230.140.70
 > Connecting to ftp.mozilla.org (ftp.mozilla.org)|54.230.140.70|:443...
 connected.
 > HTTP request sent, awaiting response... 404 Not Found
 > 2017-03-19 12:37:09 ERROR 404: Not Found.
 >
 > Makefile:93: recipe for target 'prep' failed
 > make: *** [prep] Error 8
 > }}}

 Yeah, the stable target does seldom work on `master`, we have usually the
 `maint-` branches for that. Doing nightly builds is busted right now due
 to #21748 and PTs aren't working in nightly builds either (#21757). Thus,
 your best bet is probably using `make prep-alpha` and doing an alpha build
 and test that one.

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

Re: [tor-bugs] #21753 [Applications/Tor Browser]: Get rid of old GCC toolchain in pluggable transports macOS descriptor

[Tor Bug Tracker & Wiki]

#21753: Get rid of old GCC toolchain in pluggable transports macOS descriptor
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam21703R,|  Actual Points:
  GeorgKoppen201703, tbb-gitian  |
Parent ID:  #21328   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 However, `make prep` is failing for me on the `bug_21753_v3` branch:
 {{{
 --2017-03-19 12:37:08--
 https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/45.2.0esr-
 candidates/build2/linux-i686/xpi/ar.xpi
 Resolving ftp.mozilla.org (ftp.mozilla.org)... 54.230.140.70
 Connecting to ftp.mozilla.org (ftp.mozilla.org)|54.230.140.70|:443...
 connected.
 HTTP request sent, awaiting response... 404 Not Found
 2017-03-19 12:37:09 ERROR 404: Not Found.

 Makefile:93: recipe for target 'prep' failed
 make: *** [prep] Error 8
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21753 [Applications/Tor Browser]: Get rid of old GCC toolchain in pluggable transports macOS descriptor

[Tor Bug Tracker & Wiki]

#21753: Get rid of old GCC toolchain in pluggable transports macOS descriptor
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam21703R,|  Actual Points:
  GeorgKoppen201703, tbb-gitian  |
Parent ID:  #21328   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:2 gk]:
 > dcf: you might find this interesing while testing the switch to Go 1.7.5
 and 1.8. (If you have feedback regarding that patch I am all ears; I have
 not been doing much work in the Go cross-compiling area so far).

 I will test rebasing the 1.7.5 patch on top of `bug_21753_v3`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21558 [Core Tor/Stem]: Add Ed25519 support

[Tor Bug Tracker & Wiki]

#21558: Add Ed25519 support
---+--
 Reporter:  patrickod  |  Owner:  atagar
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Bah. Hoped to have this merged by now but sadly been too busy with work.
 Flying out on a trip until the 26th during which I won't be able to push
 but I plan to work on this branch a bit during the flight.

 Just a quick update since I hate leaving pull requests in a lurch. Sorry
 about the delay, hopefully I'll finally get this out soon after I get
 back. Thanks again for putting this together! It's a great addition. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by weasel):

 * cc: weasel (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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by weasel):

 I fixed docs/debian.html - I don't know think tor-relay-debian is
 affected.  Please verify, then close.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by robgjansen):

 For IPs and ports, here is the related data for a direct download:
 {{{
 HOSTNAMELOCAL=onionperf
 HOSTNAMEREMOTE=onionperf
 ENDPOINTLOCAL=localhost:127.0.0.1:55998
 ENDPOINTPROXY=localhost:127.0.0.1:45640
 ENDPOINTREMOTE=onionperf.robgjansen.com:167.114.171.3:8080
 }}}

 And here is what I see for a .onion download:
 {{{
 HOSTNAMELOCAL=onionperf
 HOSTNAMEREMOTE=onionperf
 ENDPOINTLOCAL=localhost:127.0.0.1:45664
 ENDPOINTPROXY=localhost:127.0.0.1:45640
 ENDPOINTREMOTE=ih7hhuuppsy5wysu.onion:0.0.0.0:8080
 }}}

 Notice that the server listen port that was used for this download, 8080,
 is available in both cases. This will always be the same place that the
 client connects, otherwise the download won't happen.
   If my OnionPerf instance runs a server on `--tgen-listen-port=8080` and
 I instruct the client to connect to someone else's OnionPerf server at
 `--tgen-connect-port=443`, then 443 is the port that will show up in the
 download data. So I don't think we need to worry about the `--tgen-*-port`
 options.

 For IPs and hostnames, we have:
 -
 
[https://github.com/shadow/shadow/blob/46368f34f4ee8f602be226c4c16a8a6d82cd9a70/src/plugin
 /shadow-plugin-tgen/shd-tgen-transfer.c#L964 HOSTNAMELOCAL and
 HOSTNAMEREMOTE contain the result of `gethostname`] on the client and the
 server end, respectively (in onionperf, the client and server run on the
 same machine).
 - The name, IP, and port for each of the 3 ENDPOINT data items runs the
 same code:
   -
 
[https://github.com/shadow/shadow/blob/46368f34f4ee8f602be226c4c16a8a6d82cd9a70/src/plugin
 /shadow-plugin-tgen/shd-tgen-peer.c#L79 the hostname contains the result
 of `getnameinfo`],
   -
 
[https://github.com/shadow/shadow/blob/46368f34f4ee8f602be226c4c16a8a6d82cd9a70/src/plugin
 /shadow-plugin-tgen/shd-tgen-peer.c#L53 the IP contains the result of
 `getaddrinfo`].
   -
 
[https://github.com/shadow/shadow/blob/46368f34f4ee8f602be226c4c16a8a6d82cd9a70/src/plugin
 /shadow-plugin-tgen/shd-tgen-peer.c#L245 the ports are in host order].

 I'm not sure that we should change any of this...

 This is tricky, since OnionPerf could be run by a client that sits behind
 a firewall and only contributes .onion downloads, or that connects to
 someone else's OnionPerf server. These clients probably don't have FQDNs.
 They of course will have some kind of public IP address, but that won't be
 discoverable by the server end if the downloads are done over Tor. And the
 IP address assigned to it's local interface may not be the public-facing
 IP address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21774 [Core Tor/Stem]: Fix CONN_BW event listening

[Tor Bug Tracker & Wiki]

#21774: Fix CONN_BW event listening
---+
 Reporter:  timonh |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 The ConnectionBandwidthEvent overwrites the type field of the Event class.
 Therefore the method _handle_event in control.py erroneously checks if the
 connection type (if it is a ConnectionBandwidthEvent) is contained in the
 event listeners list.
 All in all you can't receive CONN_BW events in stem.
 I fixed it by renaming the type of the ConnectionBandwidthEvent to
 conn_type.

 My changes can be found here:
 https://github.com/kithack/stem/commit/23fe7b6cbd69c6209657c9531a21502a67ecf5e5

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21272 [Metrics]: Onionperf deployment

[Tor Bug Tracker & Wiki]

#21272: Onionperf deployment
-+--
 Reporter:  hiro |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by robgjansen):

 * cc: rob.g.jansen@… (removed)
 * cc: robgjansen (added)


Comment:

 I made the easy config update, so my data is now also available here:
 ​http://phantomtrain.robgjansen.com:8081/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21767 [Applications/Tor Browser]: Tor CA - .onion SSL system

[Tor Bug Tracker & Wiki]

#21767: Tor CA - .onion SSL system
--+--
 Reporter:  ikurua22  |  Owner:  tbb-team
 Type:  project   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:4 cypherpunks]:
 > Read Part 4 and part 5 aloud, gk.
 >
 > https://blog.torproject.org/blog/facebook-hidden-services-and-https-
 certs

 I did and not only aloud. There are interesting thoughts in this post, for
 sure. But no mentioning of a *centralized* Tor CA that has a root cert
 included into Tor Browser and we singing all the .onion certs.

 Apart from that does the post show a bunch of possible ways to move
 further but does not decide which to choose. That would be a good topic
 for one of our mailing lists (tor-dev maybe). Once we reach a conclusion
 on how to proceed let's file bugs for implementing that one.

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

Re: [tor-bugs] #21767 [Applications/Tor Browser]: Tor CA - .onion SSL system

[Tor Bug Tracker & Wiki]

#21767: Tor CA - .onion SSL system
--+--
 Reporter:  ikurua22  |  Owner:  tbb-team
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Read Part 4 and part 5 aloud, gk.

 https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 weasel recommends that we break the script out to its own js file, rather
 than having it inline, in both of these pages.

 Patches (to the webwml git repo) appreciated!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Apparently the same issue affects https://www.torproject.org/docs/tor-
 relay-debian :
 https://lists.torproject.org/pipermail/tor-relays/2017-March/012116.html

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

Re: [tor-bugs] #15569 [Applications/Tor Browser]: Web Notification API icons get no first party

[Tor Bug Tracker & Wiki]

#15569: Web Notification API icons get no first party
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:  #21762 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20471 [Applications/Tor Browser]: Allow javascript: links from HTTPS first party pages

[Tor Bug Tracker & Wiki]

#20471: Allow javascript: links from HTTPS first party pages
-+-
 Reporter:  mikeperry|  Owner:  ma1
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  security-slider, TorBrowserTeam201612, |
  noscript   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Please, don't reopen old fixed bugs. Having a new one for your issue
 sounds like a better plan.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21767 [Applications/Tor Browser]: Tor CA - .onion SSL system

[Tor Bug Tracker & Wiki]

#21767: Tor CA - .onion SSL system
--+--
 Reporter:  ikurua22  |  Owner:  tbb-team
 Type:  project   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 I don't think we want to get into the certificate business, definitely not
 the Tor Browser folks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21763 [Applications/Tor Browser]: Improve Cookie settings

[Tor Bug Tracker & Wiki]

#21763: Improve Cookie settings
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 You can make this permanent yourself by leaving the private browsing mode.
 That said I have a hard time understanding your use case: Why would you
 want cookies from onion sites but not secure cookies which are only being
 sent/set by HTTPS protected websites? What properties do .onion sites give
 your cookies that those coming from HTTPS protected sites lack? And what
 about non-onion traffic in general and all the other tracking mechanisms
 associated with it? Those are fine but just cookies not?

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