Re: [tor-bugs] #20488 [Core Tor/Tor]: Nickname registration message is confusing

[Tor Bug Tracker & Wiki]

#20488: Nickname registration message is confusing
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Agreed.

 (We did rip out the rest of the Named code, right?)

 (And, are there other log messages that are from back when we had the
 Named flag?)

--
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] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

[Tor Bug Tracker & Wiki]

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
failed
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201610, regression,   |  Actual Points:  0.3
  029-backport   |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:3 nickm]:
 > Are there any versions on the network that don't support EXTEND2,
 though? If not, we might be better off just using EXTEND2 unconditionally
 in this case.

 tor-spec.txt says:
 {{{
[Support for EXTEND2 was added in Tor 0.2.4.8-alpha.]

Clients SHOULD use the EXTEND format whenever sending a TAP
handshake, and MUST use it whenever the EXTEND cell will be handled
by a node running a version of Tor too old to support EXTEND2.  In
other cases, clients SHOULD use EXTEND2.

When encoding a non-TAP handshake in an EXTEND cell, clients SHOULD
use the format with 'client handshake type tag'.
 }}}

 And 0.2.4.8 is not in recommended versions, and has not been for some
 time, and the directory authorities reject descriptors less than 0.2.4.18.

 So the answer is: there are no nodes that affirmatively claim to only
 support EXTEND, but some custom or versionless implementations might not
 support it, and might not tell us. And other nodes could say they don't
 support it using the new supported protocols lines in descriptors.

 Oh, but some bridges might only support CREATE/EXTEND. I don't think this
 matters, because we use CREATE_FAST for the first hop anyway.

 So I think you're right, we should simplify this logic and just use
 TAP/EXTEND/CREATE, NTOR/EXTEND2/CREATE2. And just assume
 versionless/unknown version/etc. nodes support EXTEND2. It's not worth
 having the extra code just for a few nodes that are really old.

 The corresponding tor-spec.txt for CREATE is:

 {{{
In general, clients SHOULD use CREATE whenever they are using the TAP
handshake, and CREATE2 otherwise.  Clients SHOULD NOT send the
second format of CREATE cells (the one with the handshake type tag)
to a server directly.

Servers always reply to a successful CREATE with a CREATED, and to a
successful CREATE2 with a CREATED2.  On failure, a server sends a
DESTROY cell to tear down the circuit.

[CREATE2 is handled by Tor 0.2.4.7-alpha and later.]
 }}}

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

[tor-bugs] #20488 [Core Tor/Tor]: Nickname registration message is confusing

[Tor Bug Tracker & Wiki]

#20488: Nickname registration message is confusing
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+--
 toralf says:
 {{{
 wrt to this syslog massage : "You specified a server "zwiebeltoralf" by
 name, but the directory authorities do not have any key registered for
 this nickname"- how can I register my nickname ?
 }}}

 We should change this message to be clearer, particularly because we don't
 use the Named/Unnamed flags any more.

 We could just say "don't have any relay for this nickname".

--
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] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 And while we're doing that, let's document the poison file in the FILES
 section of the man page.

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Ah, you're right, this works fine for me:
 {{{
 src/or/tor HiddenServiceDir `mktemp -d` HiddenServicePort 80 DataDirectory
 `mktemp -d`
 }}}

 As does this:
 {{{
 src/or/tor HiddenServiceDir `mktemp -d` HiddenServicePort 80 DataDirectory
 `mktemp -d` HiddenServiceNonAnonymousMode 1 HiddenServiceSingleHopMode 1
 SocksPort 0
 }}}

 And this:
 {{{
 src/or/tor HiddenServiceDir `mktemp -d -u` HiddenServicePort 80
 DataDirectory `mktemp -d -u`
 }}}

 But not this:
 {{{
 src/or/tor HiddenServiceDir `mktemp -d -u` HiddenServicePort 80
 DataDirectory `mktemp -d -u` HiddenServiceNonAnonymousMode 1
 HiddenServiceSingleHopMode 1 SocksPort 0
 }}}

 So we need to do this:

 * Call the code that creates the directory before trying to poison single
 onion services

 And we might as well fix #20486 at the same time (document that the
 directory does not need to exist).

--
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] #20486 [Core Tor/Tor]: HiddenServiceDirectory is created if it doesn't exist (was: Create the HiddenServiceDirectory if it doesn't exist)

[Tor Bug Tracker & Wiki]

#20486: HiddenServiceDirectory is created if it doesn't exist
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, easy, doc  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  tor-hs => tor-hs, easy, doc
 * points:  0.5 => 0.1
 * type:  enhancement => defect


Old description:

> Split off #20484
>
> * Create the directory before trying to poison single onion services,
> using check_private_dir() (I think)
> * Update the man page

New description:

 Split off #20484

 * Update the man page, which incorrectly says that HiddenServiceDirectory
 must exist - tor creates the HiddenServiceDirectory if it doesn't exist

--

--
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] #20487 [Core Tor/Tor]: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?

[Tor Bug Tracker & Wiki]

#20487: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  single-onion, tor-hs  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: pastly (added)


Comment:

 Based on feedback from pastly on http://bh2lpa5qyawryvk2.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] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 Replying to [comment:1 teor]:
 > HiddenServiceDir says "DIRECTORY must be an existing directory".

 I now see that the documentation says this, but that is not the case for
 regular onion services. I don't think I've ever made a HiddenServiceDir
 before tonight.

--
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] #20487 [Core Tor/Tor]: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?

[Tor Bug Tracker & Wiki]

#20487: Should HiddenServiceNonAnonymousMode change default SocksPort to 0?
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  single-onion, tor-hs
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 If a user enables single onion services using:
 {{{
 HiddenServiceSingleHopMode 1
 HiddenServiceNonAnonymousMode 1
 }}}

 The immediately see:
 {{{
 Oct 28 13:28:46.087 [warn] Failed to parse/validate config:
 HiddenServiceNonAnonymousMode is incompatible with using Tor as an
 anonymous client. Please set Socks/Trans/NATD/DNSPort to 0, or
 HiddenServiceNonAnonymousMode to 0, or use the non-anonymous Tor2webMode.
 }}}

 I think it would be better if we automatically disabled the socks port in
 this case.

--
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] #20486 [Core Tor/Tor]: Create the HiddenServiceDirectory if it doesn't exist

[Tor Bug Tracker & Wiki]

#20486: Create the HiddenServiceDirectory if it doesn't exist
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 Split off #20484

 * Create the directory before trying to poison single onion services,
 using check_private_dir() (I think)
 * Update the man page

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

Re: [tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => tor-hs, single-onion
 * points:   => 0.2
 * version:   => Tor: 0.2.9.3-alpha


Comment:

 HiddenServiceDir says "DIRECTORY must be an existing directory".
 So I think we could split this into two bugs:
 * this bug: log a warning message that asks the user to create the hidden
 service directory, rather than logging the BUG message,
 * breaking change #20486 in 0.3.0: create the directory for the user, and
 change the man page (we create the DataDirectory for the user, why not the
 HiddenServiceDirectory?).

--
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] #20485 [HTTPS Everywhere]: new ruleset: Open Police Complaints

[Tor Bug Tracker & Wiki]

#20485: new ruleset: Open Police Complaints
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 https://openpolicecomplaints.org/ supports HTTPS

 Additional domains-
 https://www.openpolicecomplaints.org/
 https://app.openpolicecomplaints.org/

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

[tor-bugs] #20484 [Core Tor/Tor]: HiddenServiceDir must already exist when making a Single Onion Service

[Tor Bug Tracker & Wiki]

#20484: HiddenServiceDir must already exist when making a Single Onion Service
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Full 0.2.9.4 testing notes are at this [http://bh2lpa5qyawryvk2.onion/
 single onion service].

 {{{
 Oct 27 23:47:13.000 [notice] Tor 0.2.9.4-alpha (git-8b0755c9bb296ae2)
 opening log file.
 Oct 27 23:47:13.501 [notice] Tor 0.2.9.4-alpha (git-8b0755c9bb296ae2)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib
 1.2.8.
 Oct 27 23:47:13.501 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Oct 27 23:47:13.501 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
 Oct 27 23:47:13.501 [notice] Read configuration file
 "/media/b82d/x76slv/.torclient2/torrc".
 Oct 27 23:47:13.510 [notice] HiddenServiceSingleHopMode is enabled;
 disabling UseEntryGuards.
 Oct 27 23:47:13.510 [warn] HiddenServiceNonAnonymousMode is set. Every
 hidden service on this tor instance is NON-ANONYMOUS. If the
 HiddenServiceNonAnonymousMode option is changed, Tor will refuse to launch
 hidden services from the same directories, to protect your anonymity
 against config errors. This setting is for experimental use only.
 Oct 27 23:47:13.000 [warn] This copy of Tor was compiled or configured to
 run in a non-anonymous mode. It will provide NO ANONYMITY.
 Oct 27 23:47:13.000 [warn] Could not create single onion poison file
 /media/b82d/x76slv/.my-
 apache2-sos/hidden_service/onion_service_non_anonymous
 Oct 27 23:47:13.000 [warn] Failed to mark new hidden services as non-
 anonymous.
 Oct 27 23:47:13.000 [err] set_options(): Bug: Acting on config options
 left us in a broken state. Dying. (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 }}}

 But if I create the `~/.my-apache2-sos/hidden_service` directory before
 starting Tor, it starts up 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

Re: [tor-bugs] #20481 [Core Tor/Tor]: Section 3.8.1 of dir-spec is out of date again

[Tor Bug Tracker & Wiki]

#20481: Section 3.8.1 of dir-spec is out of date again
--+-
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by asn):

 * keywords:   => tor-spec


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

[tor-bugs] #20483 [User Experience/Website]: Twitter/Facebook share buttons on the donation page

[Tor Bug Tracker & Wiki]

#20483: Twitter/Facebook share buttons on the donation page
-+-
 Reporter:  arthuredelstein  |  Owner:  arthuredelstein
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:  crowdfunding
Actual Points:   |  Parent ID:  #20413
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 On our new "donation completed" page (which I imagine will say "Thank you
 for your donation!" at the top), we should include a couple of non-
 tracking social share buttons (Twitter, Facebook, etc.) That will give our
 loyal donors a chance to invite their friends to donate to Tor as well.

--
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] #20482 [Internal Services/Tor Sysadmin Team]: Please make a ldap account for Silvia

[Tor Bug Tracker & Wiki]

#20482: Please make a ldap account for Silvia
-+-
 Reporter:  isabela  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Silvia is starting next week as our service admin, would be great to have
 a torproject email for her as well as an ldap account since she will be
 logging in to our servers a lot :)

 Here is silvia's information

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 First name: Silvia
 Last name: Puglisi
 Desired uid/email alias: h...@torproject.org
 Forwarding address: sil...@nopressure.co.uk
 GPG public key fingerprint: 6864 C734 AD97 2957 FE93 8866 A384 25F1 767B
 B67C
 -BEGIN PGP SIGNATURE-

 iQIcBAEBCAAGBQJYEm1PAAoJEDIkSZQVBkx75LEQAI9D9ONf8NC4/H/ozt0bpDBL
 d0SpPglAPKWU+z7JmP3kq2DFSRL5EA5mFwCoTFWoike1vj8P+hhy/9e9LyrGaxyM
 /Q5f6A8dsV/QtkJvH54x0DUKBFA9gMU1e9vJXcTTi6hb9tqydSrZifm+Th6FcFU3
 4zCGz/xgt39NNF2fPsdf5jD2AqrJCKRvdzodR7yF6y3WdRY9prk3ahurI5ZFprw7
 OGtQFunIIq5NWc13R3R4dECqiLZQU5AMcBKMbASUbRsE0ebnjylncJJZzfGgiYb6
 mhEcfnOWYuflyPy2A5LnefZveQymdhBu3G47N/!HxpLmt6DTmtQOU+RPhc7IKrHd7
 nwtUjXSHxPz+qmBGN+lkjg4S+DkJAI2vjhWQNyxgehiWIJz/fZ+qzaiLloe7beZi
 aoXrRjzS9P+1f3aVs+o5F7Av/chqev80HpB8y3zmRecdIQhEwV+9rbn6VlTpdb9F
 0nvko2CnaVjVpHvkbrKD/FPtt40ZKoBw0WlCgkrxJsMHvY95E2y7jrHQQES9Rc29
 3mwfhsIQn46TmLUcgYfxATBaQqihZViuKdcGFCLAX/vsun/ME3lTU4ric5BIwej7
 CAFGfggvvU34DnWrAB74r5eR4HA7r1dGj/79t4vQDgoiTZa7Ht904L5RKhBtTxuq
 sWAIpQIh8zY3FbF1NiAX
 =!UkDp
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by viktorj):

 * cc: viktor_jaegerskuepper@… (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] #20442 [Applications/Tor Browser]: Backport fix for CVE-2016-5279: local path disclosure after drag and drop (bug 1249522)

[Tor Bug Tracker & Wiki]

#20442: Backport fix for CVE-2016-5279: local path disclosure after drag and 
drop
(bug 1249522)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201610R,   |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 Kathy and I did not test these patches, but they look okay.

--
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] #20427 [Applications/Tor Browser]: Could not connect to TOR Control Port

[Tor Bug Tracker & Wiki]

#20427: Could not connect to TOR Control Port
--+---
 Reporter:  Dad   |  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:
--+---

Comment (by mcs):

 If Tor Browser is starting correctly when your AV is disabled, then
 interference from the AV software must be the cause of the problem
 described by this ticket. "DisableNetwork is set" is a normal thing to see
 in the tor output when Tor Browser is opened for the first time
 (networking will be enabled after the initial Tor configuration has been
 completed).

--
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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 kzblocked reports that testing the `iat-mode=0` and `iat-mode=1` bridges
 worked. Even setting `iat-mode=0` on the client with `iat-mode=1` on the
 server worked. But also a default bridge worked, so the result may have
 been a random result of net load.

 ||server `iat-mode=0` ||client `iat-mode=0` ||works ||
 ||server `iat-mode=1` ||client `iat-mode=1` ||works ||
 ||server `iat-mode=1` ||client `iat-mode=0` ||works ||

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

Re: [tor-bugs] #20337 [Core Tor]: Support abstract namespace AF_UNIX sockets.

[Tor Bug Tracker & Wiki]

#20337: Support abstract namespace AF_UNIX sockets.
-+--
 Reporter:  yawning  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: brade, mcs (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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Here are three bridges with different iat-mode you can use to test. They
 are different ports on the same IP address.

  * `iat-mode=0`
{{{
 Bridge obfs4 23.92.21.42:46157 6B9D0823F14A53EE4283DD5A98C8364B09FD77CD
 cert=JzlfxJSDA4Utl2dJcRAktSfWX3oaQdAMxQiIkfcJWv6gYDplw1nLK/Lr0Y1PzvpEW1CzSQ
 iat-mode=0
 }}}
  * `iat-mode=1`
{{{
 Bridge obfs4 23.92.21.42:38323 C073380F2FDF6673CF411C05E4C4643858911F36
 cert=Aj5AaK4tiNGP7XDQd4JC4bn3Drh70d7IJR/i1NzsgyXPY0ZNutpmUa8SffNdfyS3YI/kRg
 iat-mode=1
 }}}
  * `iat-mode=2`
{{{
 Bridge obfs4 23.92.21.42:42285 F1CC4A7E0682438D76EB372A013799BF079C52EB
 cert=h6T53TvsO7shHwbuqSB1MZ56fuJw2fPoojkCqg15fIbgAwss/niB2Iik2cOYed77a6FhFQ
 iat-mode=2
 }}}

--
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] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Kathy and I reviewed both patches. Here are a few comments on the
 Torbutton patch:
 * In `torbutton_resizelistener.onStateChange`, the container variable can
 be removed.
 * The `extensions.torbutton.startup_resize_period` pref (aka
 `k_tb_tor_resize_warn_pref`) is never set to false and its value is never
 read, so it seems like it can be removed too.
 * Since the call to `quantizeBrowserSize()` was removed, should the entire
 `src/chrome/content/content-sizer.js` file be removed? Or will that
 functionality be reinstated?

 And here are our comments on the browser (C++) patch:
 * Please add a brief comment above
 `nsXULWindow::ResizeToRoundedDimensions()` to explain what it does (1000 x
 1000 maximum, width constrained to a multiple of 200, etc.)
 * `nsXULWindow::ResizeToRoundedDimensions()` should have `return NS_OK` at
 the end.
 * Are we sure that it is okay to remove support for the
 `extensions.torbutton.window.innerWidth` / `innerHeight` prefs? With the
 new patches, there is no way for the user to override the initial window
 size unless they disable fingerprinting protection. That might be okay,
 but I think people who have set these prefs in the past will be surprised.

 A related issue (but not really for this ticket) is that constraining the
 width to a multiple of 200 might be annoying on Android devices that have
 narrow screens (old phones)?

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:97 karsten]:
 > Replying to [comment:96 iwakeh]:
 > > Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep-1027=7a33c3ed9cb1fa39b3f50e6540ca045522b46944 this
 commit].
 > > This changes the top-level name to marker and host, i.e. 'Relay-
 collector.torproject.org/...'
 >
 > Looks good, merged, and resumed testing.

 FYI, pushed another commit as fixup of that last commit.  (The path had to
 be changed in two places.)  Testing more over night.

--
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] #20481 [Core Tor/Tor]: Section 3.8.1 of dir-spec is out of date again

[Tor Bug Tracker & Wiki]

#20481: Section 3.8.1 of dir-spec is out of date again
--+-
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 We've added two new consensus methods since the last update to section
 3.8.1.

 Section 3.8 has a big bulleted list under
 [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2383 "A
 router status entry"], and I think some recent consensus methods were
 erroneously added to it Consensus method 26 (initialize bw weights to 1)
 is the one I'm most familiar with that may not belong there.

 Whether or not it does belong in 3.8, method 25 and 26 are missing from
 [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2544 section
 3.8.1].

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Okay, I fixed most issues [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-20380-2 in my updated branch], except for the logging
 part.  The `-cp .:collector-.jar` part helped a bit, but now it
 complains about finding two `logback.xml` files in the classpath.  Blargh.

 Can you provide a command line that works for you?  Or can you provide a
 patch for that section?  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] #20299 [Applications/Tor Browser]: Tried to update now tor wont start

[Tor Bug Tracker & Wiki]

#20299: Tried to update now tor wont start
--+
 Reporter:  lfresh|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 lfresh: it seems you need to get rid of your `TorBrowser-Data` directory
 and then it should work again. See comment:24:ticket:13252 for where to
 look on your machine.

--
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] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

#10281: Investigate usage of alternate memory allocators and memory hardening
options
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-hardened,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

 * status:  new => assigned
 * priority:  High => Very High
 * owner:   => arthuredelstein


--
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] #14270 [Applications/Tor Browser]: Make Tor Browser work with Unix Domain Socket option

[Tor Bug Tracker & Wiki]

#14270: Make Tor Browser work with Unix Domain Socket option
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  project | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201610  |  Actual Points:
Parent ID:  #19750  | Points:
 Reviewer:  |Sponsor:  SponsorU
+--
Changes (by gk):

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


Comment:

 Seems we are done here, yay!

--
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] #20185 [Applications/Tor Browser]: Tor Browser alpha is broken on Linux (and probably OS X) if directory is nested too deep

[Tor Bug Tracker & Wiki]

#20185: Tor Browser alpha is broken on Linux (and probably OS X) if directory is
nested too deep
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  TorBrowserTeam201610R |  Actual Points:
Parent ID:  #14270| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Thanks! Looks good to me now and merged to master and maint-0.2.10 (commit
 4dd8f6130f931616cf014e0ded444c30e04c8bad and
 c916965ec2fe0b29c30414bb3c0ce3bf6ca207c5).

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:96 iwakeh]:
 > Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep-1027=7a33c3ed9cb1fa39b3f50e6540ca045522b46944 this
 commit].
 > This changes the top-level name to marker and host, i.e. 'Relay-
 collector.torproject.org/...'

 Looks good, merged, and resumed testing.

--
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] #19831 [Metrics/CollecTor]: Change default for compressing descriptors to true

[Tor Bug Tracker & Wiki]

#19831: Change default for compressing descriptors to true
---+-
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Looks good, merged.  Closing.  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] #20480 [Metrics/Consensus Health]: Faravahar is not showing up in graphs on consensus health

[Tor Bug Tracker & Wiki]

#20480: Faravahar is not showing up in graphs on consensus health
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   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] #20470 [Applications/Tor Browser]: Move security slider to about:preferences#security

[Tor Bug Tracker & Wiki]

#20470: Move security slider to about:preferences#security
--+--
 Reporter:  8u9H  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * owner:   => tbb-team
 * component:  - Select a component => Applications/Tor Browser


--
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] #16375 [Applications/Tor Browser]: Firefox bug - "Paste & Go" overwrites current text. (was: TorBrowser 4.5.1 Right mouse button menu item "Paste & go" works as "Clear, paste & go".)

[Tor Bug Tracker & Wiki]

#16375: Firefox bug - "Paste & Go" overwrites current text.
--+--
 Reporter:  Ilya_SpongeBob|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * status:  assigned => closed
 * resolution:   => wontfix
 * severity:   => Normal


Comment:

 RESOLVED WONTFIX by Mozilla:
 https://bugzilla.mozilla.org/show_bug.cgi?id=652356.
 Discussion about that is here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=628008.

--
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] #20479 [Applications/Tor Browser]: make closing and restart of Tor Browser as good as New Identity

[Tor Bug Tracker & Wiki]

#20479: make closing and restart of Tor Browser as good as New Identity
--+--
 Reporter:  adrelanos |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When using Tor Browser New Identity, it sends signal newnym and restarts
 the browser.

 Manually terminating the browser and restarting it however does not result
 in sending signal newnym.

 I would suggest to make make the shutdown / restart of Tor Browser as
 similar as it can get. I.e. when Tor Browser gets closed or started, why
 not send signal newnym?

 Are there any other differences between Tor Browser New Identity and Tor
 Browser restart that could be sorted out?

 This is specifically important for users that use system Tor, which
 includes Whonix [as well as Tails?]. Because there, Tor keeps running
 after Tor Browser was closed. Which leads to subtle differences (Tor
 circuit reuse across browser restarts for system Tor users).

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * priority:  Medium => High
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.3.0.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] #20185 [Applications/Tor Browser]: Tor Browser alpha is broken on Linux (and probably OS X) if directory is nested too deep

[Tor Bug Tracker & Wiki]

#20185: Tor Browser alpha is broken on Linux (and probably OS X) if directory is
nested too deep
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201610R |  Actual Points:
Parent ID:  #14270| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201610 => TorBrowserTeam201610R
 * status:  needs_revision => needs_review


Comment:

 We forgot to append "/Tor" in the XDG_RUNTIME_DIR case. Here is a revised
 patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20185-02=4dd8f6130f931616cf014e0ded444c30e04c8bad

 We also improved some error checking, added missing braces, and fixed the
 confusing comment.
 Please review.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep-1027=7a33c3ed9cb1fa39b3f50e6540ca045522b46944 this
 commit].
 This changes the top-level name to marker and host.

--
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] #19293 [Core Tor/Tor]: Document connection-attachment and addressmapping in detail

[Tor Bug Tracker & Wiki]

#19293: Document connection-attachment and addressmapping in detail
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-docs-dev, tor-doc-modules,   |  Actual Points:  .2
  TorCoreTeam201609, TorCoreTeam201610   |
Parent ID:  #14683   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * actualpoints:   => .2


Comment:

 Done in f3e158edf7d8128d4f1e028c5604e70469730947

--
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] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

[Tor Bug Tracker & Wiki]

#14828: Multiple hidden services can share a pk_digest/service_id.
---+---
 Reporter:  yawning|  Owner:  twim
 Type:  defect | Status:
   |  needs_revision
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Minor  | Resolution:
 Keywords:  easy, tor-hs, review-group-11  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorR-can
---+---

Comment (by twim):

 Replying to [comment:22 dgoulet]:
 > That can't work (and I confirmed it with a simple test). That patch
 does: load the keys for each service then check for a duplicate key in all
 the service we have but yet our service is already in the list so you'll
 get a positive match everytime against yourself :).

 Yeah, thanks. This is because the logic appears to be kinda broken here.
 :\
 There should be a separate temp list for services which keys we want to
 load. And if loading fails, there should be no invalid services in global
 `rend_service_list`. As for now, `rend_service_list` contains also broken
 services.
 Also there is a problem if we going to call (there is no such call now)
 `rend_service_load_all_keys()` sometime after there are ephemeral services
 there: `s->directory == NULL` for them...
 I think this upper logic has to be fixed. Thoughts?

--
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please also add some note about the following to the 'common issues'
 section.

 {{{
 ERROR org.torproject.descriptor.index.DescriptorIndexCollector Cannot
 fetch remote file: 2016-10-18-17-05-00-server-descriptors
 java.io.FileNotFoundException: https://collector.torproject.org/recent
 /relay-descriptors/server-descriptors/2016-10-18-17-05-00-server-
 descriptors
 }}}

 (cf. #20430 comment:2)

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

[Tor Bug Tracker & Wiki]

#20459: ewma_cmp_cmux never considers policies different
---+---
 Reporter:  pastly |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.6.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  029-backport, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by pastly):

 Also FWIW, I'm currently running this change in small Shadow networks as
 I'm testing other things. I'm measuring kernel queue time, tor queue time,
 network throughput, and time to download. By these four metrics, this
 change doesn't hurt a relay in a small network. It also doesn't really
 seem to help.

 I started a large Shadow simulation a couple days ago, but it died
 sometime last night :(. I've started it again. I will report back when it
 has finished. I suspect the small network was too small for the difference
 to be noticeable. Namely

 - not enough channels from one relay to ~all others
 - not enough circuits per channel

 The large network has 500 relays and 7500 clients compared to the small's
 11 and 12 respectively.

--
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] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by twim):

 Replying to [comment:8 dgoulet]:
 > As far as I understand it, that function only does OP->OR or OR->OP
 meaning it can't be a middle hop and thus if it's an origin circuit, it
 must be outbound and have a cpath else we are using that function very
 wrong.

 Just checked your branch. Thanks, the condition now looks much better!
 Comments and fixed callsites look good to me also.

--
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] #19831 [Metrics/CollecTor]: Change default for compressing descriptors to true

[Tor Bug Tracker & Wiki]

#19831: Change default for compressing descriptors to true
---+-
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Low|  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  assigned => needs_review


Comment:

 Change is
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep-1027=18e542ea86a3646f60f27b011657e23b1505867d here].

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

Re: [tor-bugs] #20028 [Core Tor/Tor]: Fix typos in tor-spec.txt [circID -> CircID]

[Tor Bug Tracker & Wiki]

#20028: Fix typos in tor-spec.txt [circID -> CircID]
-+
 Reporter:  twim |  Owner:
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 My two cents. I would say that for an official spec, having a standard of
 syntax especially for technical terms, having it uniform helps avoid any
 possible confusion and helps the grepping! That's also because of my OCD
 ;).

 Food for thought: in tor code, we have two occurrences of `CircID`, one in
 a comment and the other in a log message where we have much more `circID`.
 So, if we are serious about fixing this, I would pick one standard and fix
 it in all spec/proposals and tor code. It's not that many but if the
 effort to standardize those is made, I think it's worth merging in the
 end.

 I would pick `CircID` as it's the one we use to define the cell ABI in the
 spec.

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

Re: [tor-bugs] #20403 [Metrics/Consensus Health]: Make it easier for relay operators to find their observed bandwidth

[Tor Bug Tracker & Wiki]

#20403: Make it easier for relay operators to find their observed bandwidth
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by tom):

 * owner:   => tom
 * component:  Metrics => Metrics/Consensus Health


--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

[Tor Bug Tracker & Wiki]

#20459: ewma_cmp_cmux never considers policies different
---+---
 Reporter:  pastly |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.6.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  029-backport, review-group-11  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dgoulet):

 FWIW, I've been running this in the test network and on my real network
 relay for >24h. I'm monitoring both of them so I'll inform if anything
 blow up but so far so good. Although, I'm having a hard time so see how we
 can measure the effect of this fix except using shadow at large scale with
 a before and after.

--
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] #17975 [Core Tor/Tor]: Introduce OutboundExitAddress to enable exit-only traffic to go via a different IP address

[Tor Bug Tracker & Wiki]

#17975: Introduce OutboundExitAddress to enable exit-only traffic to go via a
different IP address
-+-
 Reporter:  naif |  Owner:
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  lorax, yawning, isaremoved, review-  |  Actual Points:
  group-11   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I put the patch in my personal repo to make it easier to review and
 comment: `ticket17975_030_01`.

 Please feel free to take it somewhere or gitlab merge request or whatever.
 The commit message and author should be changed!

--
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] #17689 [Metrics/Consensus Health]: Depictor should use extra-info fields for download times

[Tor Bug Tracker & Wiki]

#17689: Depictor should use extra-info fields for download times
--+-
 Reporter:  tom   |  Owner:  Tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by tom):

 * component:  Archived/general => Metrics/Consensus Health


--
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] #15475 [Internal Services/Tor Sysadmin Team]: Enable access to historical consensus health pages

[Tor Bug Tracker & Wiki]

#15475: Enable access to historical consensus health pages
-+-
 Reporter:  tom  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tom):

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


Comment:

 We don't gzip things anymore, so they would work without this needing to
 be done.

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

Re: [tor-bugs] #20464 [Metrics/Consensus Health]: Consensus-Health vote_data table gets out of date when a dirauth is added

[Tor Bug Tracker & Wiki]

#20464: Consensus-Health vote_data table gets out of date when a dirauth is 
added
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by tom):

 * component:  - Select a component => Metrics/Consensus Health


--
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] #20478 [Internal Services/Service - trac]: Create Metrics/Consensus Health component

[Tor Bug Tracker & Wiki]

#20478: Create Metrics/Consensus Health component
--+-
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Consensus Health does not have a Trac component, which we should fix.  I'm
 creating this ticket to document this change.

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

Re: [tor-bugs] #20478 [Internal Services/Service - trac]: Create Metrics/Consensus Health component

[Tor Bug Tracker & Wiki]

#20478: Create Metrics/Consensus Health component
--+
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by karsten):

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


Comment:

 Done.  Closing.

--
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] #9571 [Applications/Tor bundles/installation]: Tor donwloads stop

[Tor Bug Tracker & Wiki]

#9571: Tor donwloads stop
-+-
 Reporter:  Joserichi|  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   | Resolution:  user
 Severity:  Normal   |  disappeared
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * status:  needs_information => closed
 * version:  Tor: unspecified =>
 * resolution:   => user disappeared
 * severity:   => Normal


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

Re: [tor-bugs] #18502 [Applications/Orbot]: Orbot tries to kill Tor processes it doesn't own

[Tor Bug Tracker & Wiki]

#18502: Orbot tries to kill Tor processes it doesn't own
+--
 Reporter:  akwizgran   |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  orbot kill briar|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by bugzilla):

 Killer feature :)))

--
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] #20403 [Metrics]: Make it easier for relay operators to find their observed bandwidth

[Tor Bug Tracker & Wiki]

#20403: Make it easier for relay operators to find their observed bandwidth
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:2 teor]:
 > Replying to [comment:1 tom]:
 > > So depictor (consensus-health) uses stem to get its info, so it's
 really easy for me to include any information here:
 https://stem.torproject.org/api/descriptor/router_status_entry.html   It's
 really difficult to get anything else - downloading descriptors for the
 network would take a _lot_ of time, just downloading the votes and
 consesnsuses takes 10+ minutes.
 >
 > I think I might be asking for the "bandwidth (int) -- bandwidth claimed
 by the relay (in kb/s)", but I am not sure how it is sourced.

 So I'm pretty sure stem's documentation is wrong.

 On my relay (rittervg)'s
 consensus.routers['C0EDB08D7540D1DD3CA69809ED17D979F51B66E3']
 https://atlas.torproject.org/#details/C0EDB08D7540D1DD3CA69809ED17D979F51B66E3
 RouterStatusEntry:

  - .is_unmeasured is false
  - .measured is empty
  - .bandwidth is the value from the consensus w line (the agreed upon
 value by the bwauths)

 If I manually pull all the server descriptors (which I'm trying to avoid
 but I guess I could) I get the following new values:

  - .observed_bandwidth - 1434333
  - .average_bandwidth - This is the value Atlas displays under 'Advertised
 Bandwidth'
  - .burst_bandwidth - 1536000

 My relay's torrc says

  - RelayBandwidthRate 1250 KBytes
  - RelayBandwidthBurst 1500 KBytes

 > > I'm a little confused by the terms you're using.  When you say
 "observed bandwidth" do you mean the relay's 'advertised bandwidth' a
 relay operator puts in the config, the unit-less values the bwauths
 calculate and vote on, or a third thing I'm not recalling? (And if it is
 the third thing, where does that get exposed: Consensus, MicroConsensus,
 Descriptor, Microdescriptor, or ExtraInfo?)
 >
 > By "observed bandwdith" I mean the "bandwdith-observed" figure from the
 descriptor "bandwdith" line:
 > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418
 >
 > I'd like it more easily available because it's one of the two figures
 that an operator doesn't set themselves - the other is the measured
 bandwidth.
 >
 > And used in conjunction with the advertised bandwidth to calculate the
 bandwidth in the consensus "w" line:
 > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2268
 >
 > (That figure is useful, but more confusing, because it's sometimes the
 advertised bandwidth, and sometimes the observed bandwidth.)

 And .observed_bandwidth from the descriptor also

 > >  And then the same question for "consensus weight".
 >
 > Whatever Atlas uses for consensus weight in the relay details page.
 > I assume it's measured bandwidth from the consensus w line, but I'm not
 sure.
 >
 > If it is, it's already there in the consensus column of the relay flags
 table.
 >
 > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2274



 Yes, I'm 95% sure this is working correctly currently.



 > > Looking closer at the stem documentation, I might have done things
 wrong in #20372 actually. Adding Damian to confirm the below is correct:
 > >
 > > - On a vote .measured is the bwauth's vote for the relay's (unitless)
 bandwidth value
 > > - On a consensus .measured is the average* of the bwauths votes for
 the relay's (unitless) bandwidth value
 > > - On a vote or consensus .bandwidth is the _relay's_ advertised
 bandwidth (and is what teor wants available)
 >
 > Not quite, I think it's the minimum of advertised and observed, which
 confuses a lot of operators, because sometimes it's controlled by the
 torrc, and other times by their relay's self-reported performance:
 > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n418
 >
 > > *not really average but let's pretend it is for simplicity
 >
 > (low-median)

 Ah interesting, so it just takes the median value (and if there's an even
 number, the lower of the two in the middle?  Didn't realize that.


 > > (Currently, the value on each Authority is the .measured but the value
 on the consensus is .bandwidth - which would be wrong as the consensus
 would be reporting the self-reported advertised bandwidth...)
 >
 > That's strange, because all the figures in the table appear to be a low-
 median (consensus .measured) to me.

 Yup, turns out the stem documentation seems to be wrong.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

Re: [tor-bugs] #4522 [Applications/Tor Browser]: Add privilege separation for bundled browser

[Tor Bug Tracker & Wiki]

#4522: Add privilege separation for bundled browser
--+--
 Reporter:  kteel |  Owner:  tbb-team
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sandboxing|  Actual Points:
Parent ID:  #19750| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * owner:  cypherpunks => tbb-team
 * keywords:  needs-triage => tbb-sandboxing
 * parent:   => #19750


--
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] #14828 [Core Tor/Tor]: Multiple hidden services can share a pk_digest/service_id.

[Tor Bug Tracker & Wiki]

#14828: Multiple hidden services can share a pk_digest/service_id.
---+---
 Reporter:  yawning|  Owner:  twim
 Type:  defect | Status:
   |  needs_revision
 Priority:  Very Low   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.7
 Severity:  Minor  | Resolution:
 Keywords:  easy, tor-hs, review-group-11  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * points:  small => 0.1


Comment:

 That can't work (and I confirmed it with a simple test). That patch does:
 load the keys for each service then check for a duplicate key in all the
 service we have but yet our service is already in the list so you'll get a
 positive match everytime against yourself :).

--
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] #19831 [Metrics/CollecTor]: Change default for compressing descriptors to true

[Tor Bug Tracker & Wiki]

#19831: Change default for compressing descriptors to true
---+-
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  assigned
 Priority:  Low|  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * milestone:  CollecTor 1.2.0 => CollecTor 1.1.0


--
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] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
-+
 Reporter:  twim |  Owner:  twim
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  review-group-11  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Hey thanks for this twim! Good find!

 So I had to think hard about this one as it has quite a bit of implication
 especially when adding an assert like that. I've refactored your branch
 slightly (and fixing couple things) in this branch: `bug20376_030_01`.

 The main part you'll notice is the change to
 `relay_send_command_from_edge_()` which I turned into a simple if/else (no
 unknown else condition anymore) where we either have a origin circuit or
 not and depending on that, we set the direction and assert on the
 `cpath_layer` which MUST be present if we are outbound. As far as I
 understand it, that function only does OP->OR or OR->OP meaning it can't
 be a middle hop and thus if it's an origin circuit, it must be outbound
 and have a cpath else we are using that function very wrong.

 Plausible?

 The branch passes `make test-network-all`.

--
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] #10144 [Applications/Tor Browser]: "Never allow" doesn't work in the canvas popup

[Tor Bug Tracker & Wiki]

#10144: "Never allow" doesn't work in the canvas popup
--+---
 Reporter:  cypherpunks   |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

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


Comment:

 Works, but can't be reverted back in Permissions, though.

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

Re: [tor-bugs] #19292 [Core Tor/Tor]: Document main event loop actions in detail

[Tor Bug Tracker & Wiki]

#19292: Document main event loop actions in detail
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-docs-dev, tor-doc-modules,   |  implemented
  TorCoreTeam201609, TorCoreTeam201610   |  Actual Points:  .5
Parent ID:  #14683   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * status:  assigned => closed
 * resolution:   => implemented
 * actualpoints:   => .5


Comment:

 dc79504e2abc50921963a50671d122287d6a65c5 should cover 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] #9541 [Applications/Tor Browser]: "Work Offline" button should stop/start tor (as well)

[Tor Bug Tracker & Wiki]

#9541: "Work Offline" button should stop/start tor (as well)
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by bugzilla):

 * status:  new => needs_information
 * severity:   => Normal


Comment:

 Options:
 1. Stop/Start/Restart Tor from the controller/Torbutton (from GUI).
 2. Make Tor "Work Offline" (comment:5).
 3. Leave as is.

 > I frequently need to do this.
 For what purpose?

--
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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research,|  Actual Points:
  TorCoreTeam201610, review-group-11 |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:37 dgoulet]:
 > Ok so I can see how this is useful and plausibly works well. But my main
 concern here is that we are making that function _more_ complicated now
 with more if/else thus possible culprit for something that is very
 important to get right.
 >
 > We could maybe break it down more in more granular functions and improve
 testing drastically. Thoughts?

 I do agree that it would be great to have it simpler. atm I don't see any
 point where it could be broken down.
 Please leave your comments at
 https://gitlab.com/nogoegst/tor/merge_requests/1 if you have any
 ideas/confusions. 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] #19680 [Core Tor/Stem]: Pep8 renamed to pycodestyle

[Tor Bug Tracker & Wiki]

#19680: Pep8 renamed to pycodestyle
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  testing, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by neel):

 I have created a patch and uploaded it to GitHub Gist at this URL:
 https://gist.github.com/neelchauhan/849ef8eb7e15fb8370c653abcc5ab4e2

 (I used GitHub Gist because Trac marked this patch as "spam".)

 Sorry if there are mistakes with this patch, but this is my first to Stem.

--
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] #16364 [Applications/Tor Browser]: Add an option to resize the browser window to the "safe default"

[Tor Bug Tracker & Wiki]

#16364: Add an option to resize the browser window to the "safe default"
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting-   |  Actual Points:
  resolution |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  tbb-usability => tbb-usability, tbb-fingerprinting-resolution
 * type:  enhancement => defect
 * severity:   => Normal


Comment:

 Well, that's what your Resist Fingerprinting checkbox should do when it
 becomes checked (from unchecked).
 As there is no such warning for resizing, maximization warning could be a
 special way to restore the size.

--
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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:  twim
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research,|  Actual Points:
  TorCoreTeam201610, review-group-11 |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_information


Comment:

 Ok so I can see how this is useful and plausibly works well. But my main
 concern here is that we are making that function _more_ complicated now
 with more if/else thus possible culprit for something that is very
 important to get right.

 We could maybe break it down more in more granular functions and improve
 testing drastically. Thoughts?

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 New bug, though I'm not certain yet where to fix it: the
 `DescriptorIndexCollector` instance of one module deletes the synchronized
 descriptors stored by the instance of another module.  Look at the
 following (new) code:

 {{{
 DescriptorCollector dc =
 DescriptorSourceFactory.createDescriptorCollector();
 dc.collectDescriptors("https://collector.torproject.org;,
 new String[] { "/recent/torperf/" }, 0L, new File("sync"), true);
 dc.collectDescriptors("https://collector.torproject.org;,
 new String[] { "/recent/exit-lists/" }, 0L, new File("sync"),
 true);
 }}}

 What would you expect that code to do?  Populate two local directories
 `sync/recent/torperf/` and `sync/recent/exit-lists/`?  Not quite, the last
 line clears all descriptors in `sync/recent/torperf/`.  Uhm.  And I'm
 not even sure what `DescriptorCollectorImpl` would do, possibly the same
 thing.

 We can either work around this in CollecTor by using separate
 subdirectories for the modules, like
 `sync/Relay/collector.torproject.org/recent/relay-descriptors/...`, or we
 can decide this is a (usability) bug in metrics-lib, put out a 1.5.1, and
 switch.

--
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] #13926 [Applications/Tor Browser]: No certificate hierarchy

[Tor Bug Tracker & Wiki]

#13926: No certificate hierarchy
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:  tbb-usability, ff38-esr => tbb-usability


Comment:

 `TypeError: cert is null` continues to appear in ESR45 if you select
 Intermediate CA in the hierarchy (https://blog.torproject.org/blog/tor-
 browser-65a3-released#comment-209108).
 EV certs have a special handling, so when TBB seems to forget hierarchy
 for the site (not for CertViewer), some weird effects occur.

--
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:14 karsten]:
 > ...
 > >  Maybe also mention that we use 'slf4j-api' throughout.  Thus, your
 free to use the logging framework of your choice, i.e. any other
 implementation of slf4j could be chosen and provided to CollecTor.
 >
 > Do you think the average operator will care?  They'd have to provide a
 .jar file with the logging implementation.  Is this our audience?
 >

 Could be that some operators happen to be more familiar with something
 else and prefer using that.  Mentioning that we use slf4j and don't insist
 on logback would make things easier for them and others shouldn't be
 confused by that.  But, if you think it causes confusion just disregard
 this.

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

Re: [tor-bugs] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

[Tor Bug Tracker & Wiki]

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
failed
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201610, regression,   |  Actual Points:  0.3
  029-backport   |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Are there any versions on the network that don't support EXTEND2, though?
 If not, we might be better off just using EXTEND2 unconditionally in this
 case.

--
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] #15030 [Applications/Tor Browser]: Tor Browser 4.5a4 does not cope with certain self signed certificate setups.

[Tor Bug Tracker & Wiki]

#15030: Tor Browser 4.5a4 does not cope with certain self signed certificate
setups.
--+--
 Reporter:  yawning   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 Replying to [ticket:15030 yawning]:
 > On certain affected sites, "Add Exception" does nothing useful, except
 display the same error page, and disable the "Add Exception" button.
 Looks like incompatibility of `about:certerror` with NoScript. Not
 reproducible on ESR45.
 > Per GeKo on IRC: "seems Tor Browser can't cope with two self-signed
 certs in a row. this is a bug"
 OK, with 10 in a row.
 > Test URL: https://hkps.pool.sks-
 keyservers.net/pks/lookup?op=vindex=8A6EC81A
 Note that it gives a new cert even after Ctrl+F5!

--
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Getting close:

 The web application directory in [https://gitweb.torproject.org/karsten
 /metrics-
 
db.git/tree/INSTALL.md?h=task-20380-2=72923725d92b82b3164a91c74b390cf8f8cc79c0#n153
 line 153] doesn'd need to be a subdirectory of the working directory.  The
 webapp-files of collector need to be copied to an html-document directory
 apache serves; and  and  could be linked there.

 Logging:

 What exact command line did you use?
 Logback looks for a file named 'logback.xml' (or its groovy analog) in the
 classpath, i.e. if your edited 'logback.xml' is in the local path you need
 to set `-cp .:collector-.jar`.
 An easier way to debug logback: set `` at the
 beginning of the logback.xml.   That will print lots of logging debug info
 to std-out.

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

Re: [tor-bugs] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  implemented
  deferred-20161005, CoreTorTeam201610   |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


--
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] #20060 [Core Tor/Tor]: torspec patch for new bandwidth weight defaults

[Tor Bug Tracker & Wiki]

#20060: torspec patch for new bandwidth weight defaults
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, nickm-|  Actual Points:
  deferred-20161005, CoreTorTeam201610   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 merged!

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

Re: [tor-bugs] #20048 [Core Tor/Tor]: Introduce `smartlist_add_strdup()` function

[Tor Bug Tracker & Wiki]

#20048: Introduce `smartlist_add_strdup()` function
-+
 Reporter:  asn  |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  easy, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Merged; thank you!

--
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:12 iwakeh]:
 >
 > This looks good!  The new sections make it a lot easier to read (also
 during review :-)

 Glad to hear!

 > A few small things:
 >
 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n129
 line 129]: 

 Or let's just create that directory in the script if it doesn't exist.  No
 reason to do this for `ARCHIVEDIR` and not for `TARBALLTARGETDIR`.

 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n150
 line 150 and 155]: 

 Fixed.

 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n175
 line 175]: 

 Fixed.

 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n180
 line 180]: 'logback.xml' has to be available in the java classpath the
 name shouldn't change.

 Hmm, when I last tested this I only succeeded when renaming the file, but
 now that doesn't work anymore.  What I did was copy
 `src/main/resources/logback.xml` to the working directory and edit the
 `logfile-base` property to `"${LOGBASE}/colector-"`, yet that change gets
 disregarded.  What am I doing wrong?

 >  Maybe also mention that we use 'slf4j-api' throughout.  Thus, your free
 to use the logging framework of your choice, i.e. any other implementation
 of slf4j could be chosen and provided to CollecTor.

 Do you think the average operator will care?  They'd have to provide a
 .jar file with the logging implementation.  Is this our audience?

 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n188
 line 188]: Missing option `-DLOGBASE=`,

 In fact, I left that out on purpose, because it was disregarded in my
 earlier testing.  Same issue as above, what am I doing wrong?

 >  and maybe add 'the -Xmx option is based on 4g RAM here, if your machine
 has more feel free to adapt this as needed'

 Added a line for that.

 > * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n225
 line 225]:  This is still based on the assumption everything lives below
 the workdir, which doesn't need to be the case.  Maybe, change along the
 line 'A backup of your CollecTor instance should include the 
 and your configuration and other changes, which makes it possible to set-
 up this instance again.  A backup for short term recovery would also
 include the more volatile data in ,  Addendum:
 >
 > The shell script can also be anywhere as long a the paths are set
 correctly.

 Changed.

 Please find [https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-20380-2 my branch task-20380-2] with some changes.  I
 guess the only part that needs fixing before we merge is the logging
 section, plus the things that I overlooked.

--
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] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Another thing that confused me (and might tie to my comments above): if I
 am on "low" and disable JS via the NoScript button and then click on the
 Restore Defaults one the NoSrcipt button does not change. It does not do
 so even if I close the dialog. Changes the tab or reloading the page does
 change it, though.

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:7 gk]:
 > So, I played around with
 :)
 > My biggest objection to it is that buttons are missing.
 That's a violation of GUI guidelines.
 > I was quite confused as every other dialog opening in the browser has at
 least a Cancel/Close button and was wondering whether I really should
 click on the red and dangerous "x" (it's red for a reason, right?).
 Yes, it's for discarding the changes.
 > I finally concluded, "yes, that's obviously the intention" and pressed
 it anxiously.
 Booom :)
 > So, I think this is not going to fly with a user who is supposed to
 acknowledge possibly changes by clicking on a button that screams
 "Abort!!1! Danger!1!!". (the situation might be different for the mobile
 browser, though)
 (yeah, ux team is doing something strange for mobile...)
 > What about just a "Close" button? I don't know but I suspect users are
 starting to ask whether the changes really got applied (if they made
 some).
 Test the users ;)

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-usability, tbb-security-slider, TorBrowserTeam201610R =>
 tbb-usability, tbb-security-slider, TorBrowserTeam201610


Comment:

 So, I played around with the patch a bit. My biggest objection to it is
 that buttons are missing. I was quite confused as every other dialog
 opening in the browser has at least a Cancel/Close button and was
 wondering whether I really should click on the red and dangerous "x" (it's
 red for a reason, right?). I finally concluded, "yes, that's obviously the
 intention" and pressed it anxiously. So, I think this is not going to fly
 with a user who is supposed to acknowledge possibly changes by clicking on
 a button that screams "Abort!!1! Danger!1!!". (the situation might be
 different for the mobile browser, though)

 What about just a "Close" button? I don't know but I suspect users are
 starting to ask whether the changes really got applied (if they made
 some).

 Apart from that, clicking on the slider level to adjust the slider is not
 working anymore. We should retain that option.

--
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] #20048 [Core Tor/Tor]: Introduce `smartlist_add_strdup()` function

[Tor Bug Tracker & Wiki]

#20048: Introduce `smartlist_add_strdup()` function
-+
 Reporter:  asn  |  Owner:
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * keywords:  easy => easy, TorCoreTeam201610
 * status:  needs_revision => merge_ready


Comment:

 Looks good to me, let's get this merged.
 And 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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 That's ok, and thanks, I'll test the control socket fix when it appears in
 the alphas.

--
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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:33 teor]:
 > Is that nightly build supposed to contain the control socket space fix
 from #20111?
 > Because it broke, and I had to set
 extensions.torlauncher.control_port_use_socket to false to get any Tor
 Browser to work, even 6.0.5. (They all share the same extensions, because
 the extensions are in Application Support, too.)

 *sigh*, sorry for that. I rebuilt the browser part lately quite often in
 my nightly setup to test various browser fixes. While reviewing and
 testing #20111 I copied the torbutton/tor-launcher .xpi over from a local
 build to avoid the overhead from our Gitian buils setup. To answer your
 question directly: no, the fix for #20111 is not in that bundle yet.

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

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I couldn't reproduce the text field window dragging behaviour using the
 alpha, so it's no worse than 6.0.5. And the window dragging for the
 titlebar works. 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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Is that nightly build supposed to contain the control socket space fix
 from #20111?
 Because it broke, and I had to set
 extensions.torlauncher.control_port_use_socket to false to get any Tor
 Browser to work, even 6.0.5. (They all share the same extensions, because
 the extensions are in Application Support, too.)

--
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] #20048 [Core Tor/Tor]: Introduce `smartlist_add_strdup()` function

[Tor Bug Tracker & Wiki]

#20048: Introduce `smartlist_add_strdup()` function
--+
 Reporter:  asn   |  Owner:
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.3
 Reviewer:|Sponsor:
--+

Comment (by icanhasaccount):

 Thank you all for your patience/help. I've read through the coding
 standards doc properly and setup chutney etc. I've put a branch with the
 changes thus far on github: https://github.com/mintytoast/tor-
 work/tree/bug20048

--
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] #20128 [Metrics/CollecTor]: Make CollecTor operators aware of logging

[Tor Bug Tracker & Wiki]

#20128: Make CollecTor operators aware of logging
---+
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by iwakeh):

 * status:  needs_information => closed
 * resolution:   => fixed
 * milestone:  CollecTor 1.2.0 =>


Comment:

 Removed milestone and closing, because this all is addressed in #20380
 now.

 If I overlooked anything, please re-open.

 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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Addendum:

 The shell script can also be anywhere as long a the paths are set
 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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 This looks good!  The new sections make it a lot easier to read (also
 during review :-)

 A few small things:

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n129
 line 129]: 

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n150
 line 150 and 155]: 

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n175
 line 175]: 

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n180
 line 180]: 'logback.xml' has to be available in the java classpath the
 name shouldn't change.  Maybe also mention that we use 'slf4j-api'
 throughout.  Thus, your free to use the logging framework of your choice,
 i.e. any other implementation of slf4j could be chosen and provided to
 CollecTor.

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n188
 line 188]: Missing option `-DLOGBASE=`, and maybe add 'the
 -Xmx option is based on 4g RAM here, if your machine has more feel free to
 adapt this as needed'

 * [https://gitweb.torproject.org/karsten/metrics-
 
db.git/tree/INSTALL.md?h=task-20380=eba2e3f714f1d676ff811b60380fff36f74ad5cd#n225
 line 225]:  This is still based on the assumption everything lives below
 the workdir, which doesn't need to be the case.  Maybe, change along the
 line 'A backup of your CollecTor instance should include the 
 and your configuration and other changes, which makes it possible to set-
 up this instance again.  A backup for short term recovery would also
 include the more volatile data in , 
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] #20291 [Applications/Tor Browser]: Create user experience for security slider on Android (wireframes)

[Tor Bug Tracker & Wiki]

#20291: Create user experience for security slider on Android (wireframes)
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  android, ux-mobile, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by bugzilla):

 That's all.
 {{{
 JavaScript HTTPS only   On
 JS optimizationsOff
 HTML5 A/V   On demand
 MathML equationsOn demand
 SVG images  On demand
 SVG OpenType fonts  On demand
 WebFontsOn demand
 WebGL   On demand
 Web Audio API   On demand
 }}}

--
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] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Replying to [comment:33 arthuredelstein]:
 > I was able to reproduce this problem on a Windows machine and fixed it
 by adding a little piece of the old JS patch. It's annoying to me to have
 to add special-case code to two different files, but there is so much
 magic in Firefox window sizing that I don't know how else to do it. I
 wonder if this patch fixes the problem on your test system as well.
 >
 > Here's the new version:
 > ​https://github.com/arthuredelstein/tor-browser/commit/19459+13

 It does, neat! One nit: could you put a comment above the JS code change
 explaining what is going on? (maybe pointing to #18175 additionally?)

--
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] #20331 [Metrics/Metrics website]: Speed up Metrics graphs by up to 4 seconds

[Tor Bug Tracker & Wiki]

#20331: Speed up Metrics graphs by up to 4 seconds
-+
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Alright, I made some good progress here by switching from `read.csv()` to
 `load()`:

 https://gitweb.torproject.org/metrics-
 web.git/commit/?id=1f90b72368bfd2a15ee60efb7fbbcc62b3c03cdc

 Performance gain as compared to pre-a91f2dc:
  - userstats-relay-country: 3.0 seconds
  - userstats-bridge-country: 3.5 seconds
  - userstats-bridge-transport: 3.5 seconds
  - userstats-bridge-version: 3.5 seconds
  - userstats-bridge-combined: 2.7 seconds

 I'll call this done, in particular with regard to not overengineering
 this.  Closing.

--
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] #20429 [Applications/Tor Launcher]: TOR_SKIP_LAUNCH=1: progress window stays open

[Tor Bug Tracker & Wiki]

#20429: TOR_SKIP_LAUNCH=1: progress window stays open
-+
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability,TorBrowserTeam201610R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by gk):

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


Comment:

 Looks good to me. Applied to master, maint-0.2.10 and maint-0.2.9 (commits
 c12d56470b7164c33b3cb2e48a90dc65151a9a26,
 8aa78d3a78bbabe01759b63d837b09acdf53be42 and
 2014143e0081170267a34e3a102878999dee6a29)

--
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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I can't reliably reproduce it in TBB 6.0.5, so my best advice is to type
 some text in an editable multi-line field (like this one in Trac), and
 click and drag near the insertion point. Occasionally, the window moves,
 rather than the text being selected or moving.

--
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] #10824 [Applications/Tor Browser]: Using Firefox UI to remember history disables third party tracking/cookie protection

[Tor Bug Tracker & Wiki]

#10824: Using Firefox UI to remember history disables third party 
tracking/cookie
protection
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-usability  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by bugzilla):

 * keywords:  tbb-linkability, tbb-torbutton => tbb-linkability, tbb-
   usability
 * severity:   => Normal


Comment:

 As #20244 has been closed as fixed, this ticket gains more severity.

--
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] #8227 [Applications/Tor Browser]: Create descriptions for new Torbutton Security Prefs

[Tor Bug Tracker & Wiki]

#8227: Create descriptions for new Torbutton Security Prefs
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tbb-usability, tbb-easy, tbb-|  Actual Points:
  torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

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


Comment:

 Closed on behalf of #20291.

--
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] #5288 [Applications/Tor Browser]: Clickjacking + popups subvert TBB url-bar isolation

[Tor Bug Tracker & Wiki]

#5288: Clickjacking + popups subvert TBB url-bar isolation
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-firefox-patch  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by bugzilla):

 * severity:   => Normal
 * milestone:  TorBrowserBundle 2.3.x-stable =>


Comment:

 Maybe, TBB should ask user whether he allows new tab/window to violate
 first-party isolation...

--
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] #15954 [Applications/Tor Browser]: Canvas permission and HTTP auth still use FQDN isolation

[Tor Bug Tracker & Wiki]

#15954: Canvas permission and HTTP auth still use FQDN isolation
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 Ticket for adding to Mozilla first-party isolation effort.

--
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] #16527 [Applications/Tor Browser]: Mixed-content shield won't allow "Enable protection"

[Tor Bug Tracker & Wiki]

#16527: Mixed-content shield won't allow "Enable protection"
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-usability-|  Actual Points:
  website|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by bugzilla):

 * keywords:  mixed-content, tbb-usability => tbb-usability, tbb-usability-
 website


Comment:

 Enabling protection also leads to an endless loop, like in #18830,
 sometimes (was last seen on ESR38).

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