Re: [tor-bugs] #16650 [Obfuscation/BridgeDB]: Set up domain fronting for BridgeDB

[Tor Bug Tracker & Wiki]

#16650: Set up domain fronting for BridgeDB
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-dist, bridgedb-usability,   |  Actual Points:
  tbb-wants, usability, bridge-distribution, |
  TorCoreTeam201608  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

 * status:  new => needs_information


Comment:

 The new Google developer account is configured, and the meek reflector is
 installed. meek-server is also installed on polyanthum, as mentioned
 above. Both appear to be working, but they don't want to talk to each
 other through the Apache reverse proxy.

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

Re: [tor-bugs] #21647 [Core Tor/Tor]: Prop140: directory caches cache multiple past diffs or consensuses

[Tor Bug Tracker & Wiki]

#21647: Prop140: directory caches cache multiple past diffs or consensuses
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop140 TorCoreTeam201704  |  Actual Points:  6
Parent ID:  #13339 | Points:  2
 Reviewer:  ahf|Sponsor:  Sponsor4
---+---

Comment (by ahf):

 Started looking into this code now. Have added some comments with some
 very low hanging fruits, but I'll walk over it again tomorrow morning now
 that I have a much better idea on how this code 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] #16650 [Obfuscation/BridgeDB]: Set up domain fronting for BridgeDB

[Tor Bug Tracker & Wiki]

#16650: Set up domain fronting for BridgeDB
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-dist, bridgedb-usability,   |  Actual Points:
  tbb-wants, usability, bridge-distribution, |
  TorCoreTeam201608  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:7 isis]:
 > I've set up a new Google account for the AppEngine instance, the latter
 of which I'm setting up now. We get $300 free for the first 12 months, and
 (I believe?) we get 1GB bandwidth (per day? per month? not sure) for free.
 Beyond that, I've currently attached my corporation's credit card to it.
 Once we start using it I can get an estimate of how much it will cost
 (probably nothing) and (hopefully, if Shari says it's okay) switch it over
 to using a Tor company credit card.

 I forgot to mention that Google disabled this account I had made sometime
 during the 2017 Amsterdam meeting. They want "government issued identity
 documents" for the person known as "Tor Bridges". I could probably get a
 fake ID, but for now I just created a new account yesterday.  I didn't
 sign up for the $300 free credit, and so far it hasn't been disabled.

--
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] #16650 [Obfuscation/BridgeDB]: Set up domain fronting for BridgeDB

[Tor Bug Tracker & Wiki]

#16650: Set up domain fronting for BridgeDB
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-dist, bridgedb-usability,   |  Actual Points:
  tbb-wants, usability, bridge-distribution, |
  TorCoreTeam201608  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 Okay, meek-server is installed. Here's what I did:

 {{{
 #!/usr/bin/env bash

 GOROOT=/home/bridgedb/go

 # Download the official GoTools
 curl -O https://storage.googleapis.com/golang/go1.8.1.linux-amd64.tar.gz

 # Ensure the checksum is correct
 hash=`sha256sum go1.8.1.linux-amd64.tar.gz | cut -d ' ' -f 1`
 if [[ "$hash" !=
 "a579ab19d5237e263254f1eac5352efcf1d70b9dacadb6d6bb12b0911ede8994" ]] ;
 then
 printf "Bad download of GoTools! Hashes did not match! Exiting...\n"
 exit 127
 fi

 # Untar the archive
 tar -C "${GOROOT%%/go}" -xzf go1.8.1.linux-amd64.tar.gz

 # Add /home/bridgedb/go/bin to our PATH
 PATH="${GOROOT}"/bin:${PATH}

 export GOROOT
 export PATH

 # Go should now be installed
 if test -z `which go` ; then
 printf "It seems Go is not installed! Exiting...\n"
 exit 2
 fi

 # Create the tree for projects and dependencies
 PT_PATH=${GOROOT}/src/git.torproject.org/pluggable-transports
 X_PATH=${GOROOT}/src/golang.org/x

 for path in "$PT_PATH" "$X_PATH" ; do
 if ! test -d "$path" ; then
 mkdir -p "$path"
 fi
 done

 MEEK_REPO=https://git.torproject.org/pluggable-transports/meek
 PTLIB_REPO=https://git.torproject.org/pluggable-transports/goptlib
 CRYPTO_REPO=https://go.googlesource.com/crypto

 # Clone meek and goptlib
 cd "$PT_PATH"
 for repo in "$MEEK_REPO" "$PTLIB_REPO" ; do
 git clone $repo
 done

 # For some reason, it expects the goptlib repo to live in a directory
 # called "goptlib.git"
 mv goptlib goptlib.git

 # Clone golang.org/x/crypto
 cd "$X_PATH"
 git clone  "$CRYPTO_REPO"

 # Build meek-server
 cd "${PT_PATH}/meek/meek-server"
 go build
 }}}

--
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] #21772 [Internal Services/Tor Sysadmin Team]: Please install golang on polyanthum

[Tor Bug Tracker & Wiki]

#21772: Please install golang on polyanthum
-+-
 Reporter:  isis |  Owner:  tpa
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb |  Actual Points:
Parent ID:  #16650   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

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


Comment:

 Hi, I'm sorry, but that version of Go (go1.3.3) is so old that it cannot
 build the crypto libraries I need for meek-server. (See #16650)

 Could you please uninstall package `golang-go` on polyanthum? 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] #16650 [Obfuscation/BridgeDB]: Set up domain fronting for BridgeDB

[Tor Bug Tracker & Wiki]

#16650: Set up domain fronting for BridgeDB
-+-
 Reporter:  isis |  Owner:  isis
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-dist, bridgedb-usability,   |  Actual Points:
  tbb-wants, usability, bridge-distribution, |
  TorCoreTeam201608  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 I tried to use Debian stable's go, installed in #21772, in the following
 manner:

 {{{
 #!/usr/bin/env bash

 #GOROOT=/home/bridgedb/go
 GOPATH=/home/bridgedb/go/
 GO_BINARY=`which go`

 MEEK_REPO=https://git.torproject.org/pluggable-transports/meek
 PTLIB_REPO=https://git.torproject.org/pluggable-transports/goptlib
 CRYPTO_REPO=https://go.googlesource.com/crypto
 CONTEXT_REPO=https://golang.org/x/net/context

 if test -z "$GO_BINARY" ; then
 printf "It seems Go is not installed! Exiting...\n"
 exit 2
 fi

 PT_PATH=${GO_PATH}/src/git.torproject.org/pluggable-transports
 X_PATH=${GO_PATH}/src/golang.org/x

 for path in "$PT_PATH" "$X_PATH" ; do
 if ! test -d "$path" ; then
 mkdir -p "$path"
 fi
 done

 cd "$PT_PATH"
 for repo in "$MEEK_REPO" "$PTLIB_REPO" ; do
 git clone $repo
 done

 # For some reason, it expects the goptlib repo to live in a directory
 # called "goptlib.git"
 mv goptlib goptlib.git

 cd "$X_PATH"
 git clone  "$CRYPTO_REPO"

 mkdir net
 cd net
 git clone "$CONTEXT_REPO"

 # In  /home/bridgedb/go/src/golang.org/x/crypto/acme/autocert/autocert.go
 # and /home/bridgedb/go/src/golang.org/x/crypto/acme/autocert/cache.go
 # and /home/bridgedb/go/src/golang.org/x/crypto/acme/autocert/renewal.go
 # and /home/bridgedb/go/src/golang.org/x/crypto/acme/acme.go
 # you will need to change the line in `import(...)` which says
 #
 # "context"
 #
 # to instead be:
 #
 # context "golang.org/x/net/context"
 #
 # because Debian's go version is extremely old and package which used
 # to be at golang.org/x/net/conext is now top-level in the standard
 library.
 #
 # Next, in /home/bridgedb/go/src/golang.org/x/crypto/acme/acme.go
 # you will need to add in the `import(...) the following:
 #
 # "golang.org/x/crypto/ssh/keys"
 #
 # and then, in that same file, change all instances of "crypto.Signer" to
 # "keys.Signer".
 }}}

 This is all because Debian's go version is 1.3.3. These crypto libraries
 all expect at least go1.7.

 I'm just going to install gotools the proper way, in bridgedb's home
 directory.  I know a lot of Debian people are going to complain about
 this, but I'm sorry, this is insane and a waste of time.  I can build meek
 on my laptop just fine, with `go build`, and I should be able to do the
 same on the server.

--
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] #22005 [Applications/Tor Messenger]: Move to ESR 52

[Tor Bug Tracker & Wiki]

#22005: Move to ESR 52
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |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] #21879 [Applications/Tor Browser]: default bookmarks not used

[Tor Bug Tracker & Wiki]

#21879: default bookmarks not used
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 I just checked this on
 https://people.torproject.org/~boklm/builds/7.0a3-build4/tor-browser-
 linux64-7.0a3_en-US.tar.xz
 and the bookmarks are present. Maybe this is OS X specific?

--
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] #21445 [Applications/Tor Browser]: Launching Tor Browser from the .dmg should obviously fail or install correclty, not neither

[Tor Bug Tracker & Wiki]

#21445: Launching Tor Browser from the .dmg should obviously fail or install
correclty, not neither
--+--
 Reporter:  pastly|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ff52-esr   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arlolra):

 This is #21781 for Tor Messenger

--
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] #21781 [Applications/Tor Messenger]: Detect application is being run from the .dmg

[Tor Bug Tracker & Wiki]

#21781: Detect application is being run from the .dmg
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 See #21445 for 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] #21445 [Applications/Tor Browser]: Launching Tor Browser from the .dmg should obviously fail or install correclty, not neither

[Tor Bug Tracker & Wiki]

#21445: Launching Tor Browser from the .dmg should obviously fail or install
correclty, not neither
--+--
 Reporter:  pastly|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ff52-esr   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 This one seems like an important user facing bug: a lot of ordinary users
 fail to get Tor Browser working on their OS X and I'm generally bad at
 guessing why.

--
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] #10286 [Applications/Tor Browser]: Touch events leak absolute screen coordinates

[Tor Bug Tracker & Wiki]

#10286: Touch events leak absolute screen coordinates
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  ff52-esr, tbb-testcase, tbb-firefox-patch, |
  tbb-7.0-must, TorBrowserTeam201704 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arthuredelstein):

 On the latest Tor Browser alpha, the pref "dom.w3c_touch_events.enabled"
 is set to 2 on Windows and Linux, which means "autodetect". Autodetect
 mode results in the Touch API being exposed only when touch hardware is
 present. So we should either set it to "1" (enable) or "0" (disable) to
 ensure that JS code can't fingerprint the user's hardware.

--
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] #21961 [Applications/Tor Browser]: shoult torbrowser enable network.IDN_show_punycode by default?

[Tor Bug Tracker & Wiki]

#21961: shoult torbrowser enable network.IDN_show_punycode by default?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Another possibility is to show a warning when a homographic domain is
 displayed. Showing a punycode by default has the disadvantage that it
 becomes unreadable for non-latin domains.

--
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] #22001 [Applications/Tor Browser]: Protect against IDN-based whole-domain spoofing

[Tor Bug Tracker & Wiki]

#22001: Protect against IDN-based whole-domain spoofing
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arthuredelstein):

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


Comment:

 This is a duplicate.

--
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] #21853 [Internal Services/Service - git]: Give jgay push access to project/web/webwml.git

[Tor Bug Tracker & Wiki]

#21853: Give jgay push access to project/web/webwml.git
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


--
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] #21923 [Applications/Tor Browser]: Allowing only HTTPS JavaScript on the medium security slider level is broken

[Tor Bug Tracker & Wiki]

#21923: Allowing only HTTPS JavaScript on the medium security slider level is
broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  noscript, tbb-usability-website, |  Actual Points:
  ff52-esr, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:9 ma1]:
 > Replying to [comment:8 cypherpunks]:
 >
 > > Didn't you guess? ;-)
 > > From your URL it failed with [...]
 > > From AMO - works.
 >
 > No, I didn't and couldn't guess: those XPI files are identical (I
 sinchronize them as soon as they're signed by AMO) and they both install
 fine on a stable Firefox. Weird.
 Well, it was 'Temporary load add-on for debugging' feature :)
 > But, can you verify the bug reported here is fixed?
 Hmm, how to say? Testing revealed:
 1. https://check.torproject.org/?lang=en_US now is loading forever with no
 success (e10s), or there is OCSP failure (non-e10s).
 2. reloading youtube after high->medium gives no svg, etc (not noscript-
 related?), second reloading works.
 3. video is behind placeholder which allows video/mse, after clicking,
 reloading leads to error on video, because audio/mse is blocked (but no
 placeholder).
 4. seems it was ad video, because after enabling audio/mse from menu,
 there is an error again, because video/mse was blocked (but no placeholder
 again).
 5. strong feeling that that's not 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] #21923 [Applications/Tor Browser]: Allowing only HTTPS JavaScript on the medium security slider level is broken

[Tor Bug Tracker & Wiki]

#21923: Allowing only HTTPS JavaScript on the medium security slider level is
broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  noscript, tbb-usability-website, |  Actual Points:
  ff52-esr, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Replying to [comment:8 cypherpunks]:

 > Didn't you guess? ;-)
 > From your URL it failed with [...]
 > From AMO - works.

 No, I didn't and couldn't guess: those XPI files are identical (I
 sinchronize them as soon as they're signed by AMO) and they both install
 fine on a stable Firefox. Weird.

 But, can you verify the bug reported here is fixed?

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

Re: [tor-bugs] #22004 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox updater should use update_3 urls

[Tor Bug Tracker & Wiki]

#22004: Tor Browser Sandbox updater should use update_3 urls
--+---
 Reporter:  boklm |  Owner:  yawning
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

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


Comment:

 Replying to [comment:1 yawning]:
 > Dup of #21977?
 Ah, yes, I should have checked if there was already a ticket for that.

--
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] #22004 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox updater should use update_3 urls

[Tor Bug Tracker & Wiki]

#22004: Tor Browser Sandbox updater should use update_3 urls
--+-
 Reporter:  boklm |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Dup of #21977?

--
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] #21962 [Applications/Tor Browser]: Segmentation fault with "high" security when changing in about:addons to "Extensions" or "Appearance"

[Tor Bug Tracker & Wiki]

#21962: Segmentation fault with "high" security when changing in about:addons to
"Extensions" or "Appearance"
-+-
 Reporter:  viktorj  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-usability, ff52-esr,  |  Actual Points:
  tbb-7.0-must-alpha, TorBrowserTeam201704R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by mcs):

 * keywords:
 tbb-crash, tbb-usability, ff52-esr, tbb-7.0-must-alpha,
 TorBrowserTeam201704
 =>
 tbb-crash, tbb-usability, ff52-esr, tbb-7.0-must-alpha,
 TorBrowserTeam201704R
 * status:  new => needs_review


Comment:

 Here is our patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug21962-01=4cc114a57704a76988cb7862c6be2fd94639d144

--
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] #22004 [Applications/Tor Browser Sandbox]: Tor Browser Sandbox updater should use update_3 urls

[Tor Bug Tracker & Wiki]

#22004: Tor Browser Sandbox updater should use update_3 urls
--+-
 Reporter:  boklm |  Owner:  yawning
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In #19316 we changed the update urls from `update_2` to `update_3`. The
 sandbox updater should start using the `update_3` urls too (although in
 #22003 we are going to add redirects for Linux and OSX users, so old urls
 should keep working for a while).

--
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] #21923 [Applications/Tor Browser]: Allowing only HTTPS JavaScript on the medium security slider level is broken

[Tor Bug Tracker & Wiki]

#21923: Allowing only HTTPS JavaScript on the medium security slider level is
broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  noscript, tbb-usability-website, |  Actual Points:
  ff52-esr, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:7 ma1]:
 > Replying to [comment:5 cypherpunks]:
 > > 16:02:59.098 Error: Only restartless (bootstrap) add-ons can be
 installed from sources:
 > > Stack trace:
 > >
 
this.XPIProvider.installAddonFromLocation<@resource://gre/modules/addons/XPIProvider.jsm:4151:13
 >
 > Where are you installing the XPI from? Did you try from the URL I
 provided you with, or from AMO ( https://addons.mozilla.org/en-
 US/firefox/addon/noscript/versions/beta )?
 Didn't you guess? ;-)
 From your URL it failed with
 {{{
 1492633619500   addons.xpi  WARNDownload of
 https://secure.informaction.com/download/betas/noscript-5.0.3rc5.xpi
 failed: [Exception... "Certificate issuer is not built-in."  nsresult:
 "0x80004004 (NS_ERROR_ABORT)"  location: "JS frame ::
 resource://gre/modules/CertUtils.jsm :: checkCert :: line 171"  data: no]
 Stack trace: checkCert()@resource://gre/modules/CertUtils.jsm:171 <
 onStopRequest()@resource://gre/modules/addons/XPIProvider.jsm:6547
 }}}
 From AMO - 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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:24 boklm]:
 > When we publish the 6.5.2 release, we should upload the update manifests
 to both `update_2` and `update_3`.

 This is done.

 >
 > When we publish the 7.0 release, we should upload the new update
 manifests to `update_3` only, keeping the 6.5.2 manifests in `update_2`.
 We should also add some `update_2/release/{Linux,OSX}` ->
 `update_3/release/{Linux,OSX}` redirects as only Windows users are
 affected.

 I opened #22003 for that.

 >
 > We should also remember to keep the 6.5.2 mar files (at least the
 Windows ones) on cdn.torproject.org for a while.

 I created the file `/srv/cdn-
 master.torproject.org/htdocs/aus1/torbrowser/6.5.2-do-not-remove.txt` on
 `staticiforme` to remember that.

--
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] #21923 [Applications/Tor Browser]: Allowing only HTTPS JavaScript on the medium security slider level is broken

[Tor Bug Tracker & Wiki]

#21923: Allowing only HTTPS JavaScript on the medium security slider level is
broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  noscript, tbb-usability-website, |  Actual Points:
  ff52-esr, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Replying to [comment:5 cypherpunks]:
 > 16:02:59.098 Error: Only restartless (bootstrap) add-ons can be
 installed from sources:
 > Stack trace:
 >
 
this.XPIProvider.installAddonFromLocation<@resource://gre/modules/addons/XPIProvider.jsm:4151:13

 Where are you installing the XPI from? Did you try from the URL I provided
 you with, or from AMO ( https://addons.mozilla.org/en-
 US/firefox/addon/noscript/versions/beta )?

--
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] #22003 [Applications/Tor Browser]: Redirect Linux and OSX update URLs from update_2 to update_3

[Tor Bug Tracker & Wiki]

#22003: Redirect Linux and OSX update URLs from update_2 to update_3
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201704
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #19316 we changed the update url from `update_2` to `update_3`, to
 force Windows users to go through the 6.5.2 version, and warn them if they
 don't have SSE support. As this does not affect Linux and OSX users, we
 should add some redirects to update them directly to the new versions.

 We should do that for the `release` channel. For the `alpha` channel, we
 don't need to exclude the Windows users from the redirect as we don't have
 any alpha version that can detect SSE support, so we can redirect all
 `update_2` urls to `update_3`.

--
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] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arma):

 Replying to [comment:16 micah]:
 > redirect any user that comes from an IP in the above list to the onion
 address

 I've been recommending to websites that they *not* do this.

 First, it breaks your website the people in the case of false positives
 (e.g. where an apartment building has one IP address and one exit relay).

 But more importantly, it should be up to the users what sort of security
 properties they get while connecting to your website, and you're taking
 away their choice. Privacy is about control and choice -- putting up a
 little dynamic section of the page that says "Hey, did you know we have an
 onion address?" is great, but sending them somewhere else based on their
 IP address seems like a slippery slope.

--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:  tbb-security => ff52-esr


--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:3 gk]:
 > Oh, and where is the security angle wrt this backport?
 Part of your security slider ;)

 (Do you think any of your patches can cope with e10s (edge cases)?)

--
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] #21851 [Applications/Tor Browser]: Revert some of #18915 changes (was: Revert some of #18195 changes)

[Tor Bug Tracker & Wiki]

#21851: Revert some of #18915 changes
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704,  |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by arthuredelstein:

Old description:

> Following #21309, we may be able to revert some of the #18195 changes.

New description:

 Following #21309, we may be able to revert some of the #18915 changes.

--

--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:2 gk]:
 > Why do we want to backport that patch if things are missing and we have
 a working patch in our tree?

 We don't have to necessarily. Because the backport seemed to fix the
 crash, I was attempting to work with it, but found several missing edges
 cases. That's why I suggested in #21962 that we stick with the working
 patch, with Mark and Kathy's fixup.

 In the long run, given that we hope to reduce our maintenance by uplifting
 our SVG-disabling code, it seems to make sense that we would backport the
 Mozilla patch and add back the missing parts. Or we could ask Mozilla to
 work on that.

 FWIW, here is my WIP branch. I'm going to leave it at this stage until we
 decide on what to do.
 https://github.com/arthuredelstein/tor-browser/commits/22002_wip

--
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] #20322 [Applications/Tor Browser]: SafeSEH support for mingw-w64 for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#20322: SafeSEH support for mingw-w64 for Tor Browser on Windows
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 As there is no activity on this problem, should we proceed with the public
 disclosure?

--
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] #22001 [Applications/Tor Browser]: Protect against IDN-based whole-domain spoofing

[Tor Bug Tracker & Wiki]

#22001: Protect against IDN-based whole-domain spoofing
--+--
 Reporter:  arthuredelstein   |  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 gk):

 * keywords:  tbb-security =>
 * priority:  Very High => Medium
 * severity:  Critical => Normal


Comment:

 Arthur: what's the relationship of this bug to #21961?

--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Oh, and where is the security angle wrt this backport?

--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Why do we want to backport that patch if things are missing and we have a
 working patch in our tree?

--
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] #21962 [Applications/Tor Browser]: Segmentation fault with "high" security when changing in about:addons to "Extensions" or "Appearance"

[Tor Bug Tracker & Wiki]

#21962: Segmentation fault with "high" security when changing in about:addons to
"Extensions" or "Appearance"
-+-
 Reporter:  viktorj  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-usability, ff52-esr,  |  Actual Points:
  tbb-7.0-must-alpha, TorBrowserTeam201704   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * status:  accepted => new


Comment:

 I've been working on the backporsht approach, which does get rid of the
 crash. Unfortunately there is a lot missing from Mozilla's version that
 needs to be added back from Kathy and Mark's old SVG patch and I'm still
 debugging some issues. I'm opening a new ticket for the backport, because
 I think we should go with Mark and Kathy's old patch (with fixup) for now:
 #22002

--
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] #22002 [Applications/Tor Browser]: Backport Mozilla's SVG-disabling patch (was: Backport the SVG patch)

[Tor Bug Tracker & Wiki]

#22002: Backport Mozilla's SVG-disabling patch
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:   => tbb-security


--
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] #22002 [Applications/Tor Browser]: Backport the SVG patch

[Tor Bug Tracker & Wiki]

#22002: Backport the SVG patch
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 Mozilla partially uplifted our SVG disabling patch, but a lot of edge
 cases are left out that we need to add in order to use the uplifted patch.

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

Re: [tor-bugs] #21983 [Applications/Tor Browser]: Should we do more to discourage custom prefs and nonstandard addons?

[Tor Bug Tracker & Wiki]

#21983: Should we do more to discourage custom prefs and nonstandard addons?
-+--
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 Warning about it changes your fingerprint, linkability, etc would be good.

--
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] #22001 [Applications/Tor Browser]: Protect against IDN-based whole-domain spoofing

[Tor Bug Tracker & Wiki]

#22001: Protect against IDN-based whole-domain spoofing
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * priority:  Medium => Very High
 * keywords:   => tbb-security
 * severity:  Normal => Critical


Comment:

 Is this a way to go for malicious exit nodes?
 (Dupe of #21961?)

--
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] #21962 [Applications/Tor Browser]: Segmentation fault with "high" security when changing in about:addons to "Extensions" or "Appearance"

[Tor Bug Tracker & Wiki]

#21962: Segmentation fault with "high" security when changing in about:addons to
"Extensions" or "Appearance"
-+-
 Reporter:  viktorj  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  accepted
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-usability, ff52-esr,  |  Actual Points:
  tbb-7.0-must-alpha, TorBrowserTeam201704   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Shouldn't you just backport the Mozilla's patches?

--
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] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by micah):

 Right now, the current way that Riseup is doing this is the first one that
 asn enumerates:

 1. 1/hr cronjob that downloads the current exit list
 2. leaning on apache/nginx geoip modules to webserver redirect any user
 that comes from an IP in the above list to the onion address

 This works fairly well, I have reasonable ways to do it in apache and
 nginx. This was the mechanism that ilf and I were developing and were
 wanting to document and promote more to get onion operators to do, rather
 than trying to do this tor mapping thing.

 There are a couple cases where it doesn't work perfectly that I've run
 into:

 1. One user who runs an exit node on their home network router, NATing all
 their connections through that same IP, but does not run TBB, was unhappy
 that they were redirected to .onion sites because they didn't want to use
 TBB all the time. This was a bit of a rare case. The user agreed to try to
 use TBB instead in the future, but also was willing to provide me his
 relay FP so I could remove it from the redirect rules.

 2. One user who was concerned about the redirection, thought they had been
 hacked and were being redirected to a nefarious site.

--
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] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by guido):

 * cc: guido@… (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] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by micah):

 * cc: hacim (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] #21962 [Applications/Tor Browser]: Segmentation fault with "high" security when changing in about:addons to "Extensions" or "Appearance"

[Tor Bug Tracker & Wiki]

#21962: Segmentation fault with "high" security when changing in about:addons to
"Extensions" or "Appearance"
-+-
 Reporter:  viktorj  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  accepted
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-usability, ff52-esr,  |  Actual Points:
  tbb-7.0-must-alpha, TorBrowserTeam201704   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Kathy and I tracked down the root cause of the crash (which is also
 causing SVG images to not appear in about:preferences). Apparently, for
 some subresource documents, SVG elements are created before the document
 is attached to the parent window. This causes `NS_SVGEnabledForChannel()`
 to fail to perform its whitelist check for documents such as
 `toolkit/mozapps/extensions/content/extensions.xml` (because we end up
 with a NULL `topDocURI`), which in turn causes SVGs to be disabled at
 first and later allowed (because ultimately the subresource is part of
 about:addons, which is whitelisted).

 I am not sure what changed between Firefox 45 and 52 to cause this
 problem, but adding a check against the system principal in this specific
 case seems to fix things. It is also worth noting that Mozilla's patch for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1216893 uses
 `IsSystemPrincipal()` checks too.

 We will post a patch soon.

--
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] #21853 [Internal Services/Service - git]: Give jgay push access to project/web/webwml.git

[Tor Bug Tracker & Wiki]

#21853: Give jgay push access to project/web/webwml.git
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by jgay):

 This is no longer necessary since I am now the outgoing Communications
 Director.

--
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] #20814 [Applications/Tor Browser]: Pick a more accurate name for the "hardened" Tor Browser

[Tor Bug Tracker & Wiki]

#20814: Pick a more accurate name for the "hardened" Tor Browser
--+---
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201704  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 I made a mar file for switching a browser to the alpha channel and signed
 it:
 https://people.torproject.org/~boklm/bug_20814/switch-to-alpha.mar

 To test it I set this url as `app.update.url.override` in a 7.0a2-hardened
 browser:
 https://people.torproject.org/~boklm/bug_20814/hardened/switch-to-
 alpha.xml

 The browser found an update, and after applying it the channel was changed
 to alpha, so it seems to be working.

--
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] #22001 [Applications/Tor Browser]: Protect against IDN-based whole-domain spoofing (was: Show a warning for IDN whole-domain spoofing)

[Tor Bug Tracker & Wiki]

#22001: Protect against IDN-based whole-domain spoofing
--+--
 Reporter:  arthuredelstein   |  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:
--+--

--
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] #22001 [Applications/Tor Browser]: Show a warning for IDN whole-domain spoofing

[Tor Bug Tracker & Wiki]

#22001: Show a warning for IDN whole-domain spoofing
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 Unfortunately Mozilla doesn't look like it is going to provide protection.
 But I think we should consider doing so in Tor Browser. See
 https://bugzilla.mozilla.org/show_bug.cgi?id=1332714

--
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] #22000 [Applications/Tor Browser]: update OSX browser sandbox profile for e10s

[Tor Bug Tracker & Wiki]

#22000: update OSX browser sandbox profile for e10s
-+-
 Reporter:  brade|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff52-esr,
 Severity:  Normal   |  TorBrowserTeam201704, tbb-security,
 |  tbb-sandboxing
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:  Sponsor4 |
-+-
 For compatibility with e10s, the TB.sb file needs to be updated to allow
 creation of content processes.

--
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] #21999 [Applications/Tor Browser]: The "request English language web pages"-prompt is not working in 7.0a3

[Tor Bug Tracker & Wiki]

#21999: The "request English language web pages"-prompt is not working in 7.0a3
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff52-esr, tbb-e10s
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Using a non-en-US locale does not show the "request English language web
 pages"-prompt anymore with the switch to 7.0a3. I have not looked closer
 but I guess the progress listener is broken due to e10s.

--
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] #21998 [Applications/Tor Browser]: Add the option for debug builds to rbm

[Tor Bug Tracker & Wiki]

#21998: Add the option for debug builds to rbm
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #17379
   Points:|   Reviewer:
  Sponsor:|
--+--
 The hardened series contained features like ASan that helped us spot
 problems in our code earlier. We want to have similar nightly builds when
 switching to `rbm`. The tor-browser code still contains `.mozconfig-asan`
 which should be usable and I guess there are other things that can get
 salvaged from the descriptors in the `hardened-builds` branch 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

Re: [tor-bugs] #21988 [- Select a component]: says not usingtor

[Tor Bug Tracker & Wiki]

#21988: says not usingtor
--+--
 Reporter:  bobkat|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  invalid
 Keywords:  not using tor |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


--
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] #21932 [Metrics/metrics-lib]: Stop relying on the platform's default charset

[Tor Bug Tracker & Wiki]

#21932: Stop relying on the platform's default charset
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 See also #21933.

--
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] #21980 [Core Tor/Tor]: prop224: Implement time period functions

[Tor Bug Tracker & Wiki]

#21980: prop224: Implement time period functions
-+
 Reporter:  dgoulet  |  Owner:  asn
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  0.5
 Reviewer:  nickm|Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 @nickm, asn responded to comment.

--
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] #21932 [Metrics/metrics-lib]: Stop relying on the platform's default charset

[Tor Bug Tracker & Wiki]

#21932: Stop relying on the platform's default charset
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => needs_information


Comment:

 This ticket doesn't only address becoming independent of platform charset
 settings (which is good), but it also suggests switching from ASCII to
 UTF8.
 In many places metrics-lib currently reads also writes US-ASCII.  As far
 as the (gruesome) charset topics go, UTF8 should be a superset of ASCII.
 Starting to read and write descriptors consistently in utf8 should work
 and would be good also to accommodate some of the character in names and
 other user configurable descriptor fields.  In general, the proposed
 change seems fine.

 Is it also intended to only let metrics-lib write utf8 files with the
 proposed changes?

--
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] #21975 [Core Tor/Tor]: Refactor all the startup stuff in config.c, with dependencies in mind

[Tor Bug Tracker & Wiki]

#21975: Refactor all the startup stuff in config.c, with dependencies in mind
--+--
 Reporter:  arma  |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:   => refactor
 * milestone:   => Tor: unspecified


--
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] #21974 [Core Tor/Tor]: Race: Tor declares controlport listener open before it has written its controlcookie to disk

[Tor Bug Tracker & Wiki]

#21974: Race: Tor declares controlport listener open before it has written its
controlcookie to disk
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:   => Tor: unspecified


--
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] #21997 [Internal Services/Service - git]: tor-launcher: please delete the mater branch

[Tor Bug Tracker & Wiki]

#21997: tor-launcher: please delete the mater branch
-+
 Reporter:  mcs  |  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


Comment:

 [x]

--
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] #21791 [Internal Services/Service - git]: Give tjr permission to commit to pytorctl

[Tor Bug Tracker & Wiki]

#21791: Give tjr permission to commit to pytorctl
-+
 Reporter:  teor |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Sebastian):

 Is this something for me yet? aagbsn and mikeperry have push access atm.

--
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] #21821 [Internal Services/Service - git]: Remove debian-master branch from TorBirdy's repository

[Tor Bug Tracker & Wiki]

#21821: Remove debian-master branch from TorBirdy's repository
-+
 Reporter:  sukhbir  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Sebastian):

 Is it referred to anywhere? Should it perhaps be updated with a commit
 stating it's unused now and where to look for it now?

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

Re: [tor-bugs] #21853 [Internal Services/Service - git]: Give jgay push access to project/web/webwml.git

[Tor Bug Tracker & Wiki]

#21853: Give jgay push access to project/web/webwml.git
-+
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by Sebastian):

 Hi, is this still relevant? Sorry for not spotting it earlier.

--
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] #21997 [Internal Services/Service - git]: tor-launcher: please delete the mater branch

[Tor Bug Tracker & Wiki]

#21997: tor-launcher: please delete the mater branch
-+
 Reporter:  mcs  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 I tried to delete an old tor-launcher branch that was created by mistake,
 but my attempt failed:
 {{{
  git push origin-rw --delete mater
  remote: + refs/heads/mater tor-launcher brade DENIED by fallthru
  remote: error: hook declined to update refs/heads/mater
  To ssh://g...@git-rw.torproject.org/tor-launcher.git
   ! [remote rejected] mater (hook declined)
  error: failed to push some refs to 'ssh://g...@git-rw.torproject.org/tor-
 launcher.git'
 }}}
 My guess is that this is something that a git admin needs to do for us.

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

Re: [tor-bugs] #21255 [Metrics/Metrics website]: fraction value computation for clients.csv and its descriptions don't seem to match

[Tor Bug Tracker & Wiki]

#21255: fraction value computation for clients.csv and its descriptions don't 
seem
to match
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


Comment:

 As we plan a description of Metrics data in the near future the adaption
 here can just wait.
 Closing as won't-fix for now (which we also discussed in private mail
 before).

--
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] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => needs_information


Comment:

 Ok, I start from the opposite direction and hopefully we meet in the
 perfect middle :-)

 The use-case this ticket mostly refers to is bulk processing, i.e. there
 is a bunch of descriptors somewhere (file system, remote server) and
 metrics-lib fetches, synchronizes, and parses these files. One constraint
 is that there will always be some descriptors that cannot be parsed.

 From this scenario, I would conclude that methods like readDescriptors,
 parseDescriptors, collectDescriptors don't throw
 DescriptorParseExceptions, but simply process as much as possible and
 provide a list of problematic descriptors at the end, which the API using
 program can choose to ignore or process.
 Does this sound like the right use-case description?

 Regarding the code-example:  configuration of a descriptor source by
 fluent-style (or method chaining) is fine, but metrics-lib currently has
 the DescriptorSourceFactory approach, which would need to be adapted.
 That is, I see two things:  the ideas around the code of
 DescriptorSourceBuilder are ideas about a new way of configuration and not
 exception/error handling in metrics-lib, i.e. a different ticket (there is
 one for redesign of the interface hierarchy, I'll look for it).  Second,
 the current configuration and descriptor source instanciation need to be
 considered together (in that other ticket).

--
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] #20814 [Applications/Tor Browser]: Pick a more accurate name for the "hardened" Tor Browser

[Tor Bug Tracker & Wiki]

#20814: Pick a more accurate name for the "hardened" Tor Browser
--+---
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201704  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:19 boklm]:
 > Replying to [comment:18 gk]:
 > > boklm: do you feel you can take a look at the Mozilla bug in the
 previous comment and figure out what we need to do on our side to get
 hardened users properly onto the alpha channel?
 >
 > Yes, I think I can do that.
 >
 > What they did was create a mar file that only updates the `update-
 settings.ini` and `defaults/pref/channel-prefs.js` files to switch them to
 the esr channel. So the update to the next version is done in two steps.
 >
 > I think we can do the same. After being switched to the alpha channel,
 hardened users will get an error with the incremental update (as we can't
 differentiate users of the alpha and hardened versions at that point, and
 the incremental mar files will only apply to the alpha version), but full
 update should work.
 >
 > I will make a mar file for this to try it.

 How did the test go? Are we ready for that?

--
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] #20537 [Community/Training]: Tor Browser User Manual needs meta section

[Tor Bug Tracker & Wiki]

#20537: Tor Browser User Manual needs meta section
+
 Reporter:  weasel  |  Owner:  Kelley
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Training  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by jonathanfemideer):

 Not just ​https://tb-manual.torproject.org/windows/en-US/ . All versions
 of the manual listed here are also affected by this defect: https://tb-
 manual.torproject.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

Re: [tor-bugs] #20537 [Community/Training]: Tor Browser User Manual needs meta section

[Tor Bug Tracker & Wiki]

#20537: Tor Browser User Manual needs meta section
+
 Reporter:  weasel  |  Owner:  Kelley
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Training  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by jonathanfemideer):

 * cc: jonathanfemideer (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] #21996 [Core Tor/Tor]: Should we treat BUG messages as fatal errors during fuzzing?

[Tor Bug Tracker & Wiki]

#21996: Should we treat BUG messages as fatal errors during fuzzing?
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 That seems smart to me, if it doesn't require a huge code 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] #21978 [Core Tor/Tor]: hs: Decouple adding and validating a service

[Tor Bug Tracker & Wiki]

#21978: hs: Decouple adding and validating a service
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  0.2
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+

Comment (by asn):

 Did an initial review but there was lots of moving in the same
 commit which confused me a bit. I should probably look at it again/

--
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] #21996 [Core Tor/Tor]: Should we treat BUG messages as fatal errors during fuzzing?

[Tor Bug Tracker & Wiki]

#21996: Should we treat BUG messages as fatal errors during fuzzing?
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While wondering why #21966 wasn't caught during consdiff code fuzzing, I
 noticed that in the C implementation failing to apply a generated diff is
 not a reason to assert, but rather an LD_BUG log message is generated.
 Unapplying the 21966 fix and fuzzing promptly leads to the discovery of
 that bug. I think it might make sense to ensure any BUG message that gets
 triggered fails an assertion if we're currently fuzzing?

--
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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Sounds good. I committed your changes to `master` (commit
 70961a33301ca42b1fe3eb9eee87ea16bef4fea2).

--
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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:32 gk]:
 > Replying to [comment:30 boklm]:
 > > In my branch `bug_19316_update-responses` I added a patch to add
 support for `minSupportedInstructionSet` in the `config.yml` file:
 > > https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_19316_update-
 responses=70961a33301ca42b1fe3eb9eee87ea16bef4fea2
 > >
 > > We don't need it for this release yet, but we will need it when
 releasing 7.0.
 >
 > I already added
 > {{{
 > win32:
 > minSupportedInstructionSet: SSE2
 >
 > }}}
 > to the `config.yml` file for 7.0a3. I guess we can make use of that by
 just committing your patch to master and using that to create the update
 responses files? Or do we need to be on the exact tag for that?

 Yes, I think we can do that.

--
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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:30 boklm]:
 > In my branch `bug_19316_update-responses` I added a patch to add support
 for `minSupportedInstructionSet` in the `config.yml` file:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_19316_update-
 responses=70961a33301ca42b1fe3eb9eee87ea16bef4fea2
 >
 > We don't need it for this release yet, but we will need it when
 releasing 7.0.

 I already added
 {{{
 win32:
 minSupportedInstructionSet: SSE2

 }}}
 to the `config.yml` file for 7.0a3. I guess we can make use of that by
 just committing your patch to master and using that to create the update
 responses files? Or do we need to be on the exact tag for that?

--
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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  reopened => needs_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] #19316 [Applications/Tor Browser]: Make sure our updates are dealing with SSE requirement properly

[Tor Bug Tracker & Wiki]

#19316: Make sure our updates are dealing with SSE requirement properly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 In my branch `bug_19316_update-responses` I added a patch to add support
 for `minSupportedInstructionSet` in the `config.yml` file:
 https://gitweb.torproject.org/user/boklm/tor-browser-bundle.git/commit/?h
 =bug_19316_update-responses=70961a33301ca42b1fe3eb9eee87ea16bef4fea2

 We don't need it for this release yet, but we will need it when releasing
 7.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] #21923 [Applications/Tor Browser]: Allowing only HTTPS JavaScript on the medium security slider level is broken

[Tor Bug Tracker & Wiki]

#21923: Allowing only HTTPS JavaScript on the medium security slider level is
broken
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  noscript, tbb-usability-website, |  Actual Points:
  ff52-esr, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  noscript, tbb-usability-website, ff52-esr => noscript, tbb-
 usability-website, ff52-esr, TorBrowserTeam201704R


--
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] #13017 [Applications/Tor Browser]: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

[Tor Bug Tracker & Wiki]

#13017: Determine if AudioBuffers/OfflineAudioContext are a fingerprinting 
vector
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201702, ff52-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: Sampei (added)


Comment:

 #21984 is a duplicate.

--
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] #21984 [Applications/Tor Browser]: Tor Browser vulnerable with AudioContext Fingerprinting test

[Tor Bug Tracker & Wiki]

#21984: Tor Browser vulnerable with AudioContext Fingerprinting test
--+---
 Reporter:  Sampei|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Replying to [comment:2 arma]:
 > Looks like a subset of #13017 ?

 Yes, we track it there.

--
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] #21882 [Metrics/Consensus Health]: Graph for number of relays that bwauths decided the median for

[Tor Bug Tracker & Wiki]

#21882: Graph for number of relays that bwauths decided the median for
--+-
 Reporter:  Sebastian |  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:
--+-

Comment (by Sebastian):

 This looks great! One thing that would also be of interest to me is how
 severe the variation was. Maybe we could have a thin black line where the
 measurement disagrees more than 10% with the median?

--
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] #21995 [Metrics/Torflow]: Set PreferIPv6 on Bandwidth Scanner SOCKSPorts (was: Set PreferIPv6Traffic on Bandwidth Scanner SOCKSPorts)

[Tor Bug Tracker & Wiki]

#21995: Set PreferIPv6 on Bandwidth Scanner SOCKSPorts
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

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

[tor-bugs] #21995 [Metrics/Torflow]: Set PreferIPv6Traffic on Bandwidth Scanner SOCKSPorts

[Tor Bug Tracker & Wiki]

#21995: Set PreferIPv6Traffic on Bandwidth Scanner SOCKSPorts
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Tor Browser sets this option, so the bandwidth authorities should set it
 too. This only matters when using a bandwidth server with a DNS with IPv6
 addresses.

--
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] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distribution of a bandwidth authority's measurements?

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distribution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Old description:

> Once we know how many relays a bandwidth authority controls (#21992), we
> might want to know how much it can change their figures, or how their
> measurements are distributed.
>
> I'm not sure if we would use this, but I am writing it down so others can
> decide if they want it, and which option they want.
>
> '''Quartile Option'''
>
> This option doesn't tell us the exact range for each relay, but it's easy
> to calculate and understand.
>
> For each bandwidth authority:
> * the quartiles of its bandwidth measurements
>
> This could look like:
> https://consensus-health.torproject.org/#downloadstats
>
> '''Range Option'''
>
> This option is more specific, but might be harder to understand and use.
>
> For each bandwidth authority:
> * the median of the measurements it controls (the relays for which it is
> the median)
> * the median of the next highest measurement where it is the next highest
> measurement
> * the median of the next lowest measurement where it is the next lowest
> measurement
>
> We should probably use medians for the average, because we really don't
> care about extremes.
>
> Maybe this could look something like:
>
> '''Bandwidth Authority Variance'''
> ||  || lower || median || higher ||
> || longclaw || 27887 || 58578  || 89090  ||
> || gabelmoo || 34585 || 69344  || 84323  ||
>
> Or maybe it would be better to express them as percentages of the median.

New description:

 Once we know how many relays a bandwidth authority controls (#21992), we
 might want to know how much it can change their figures, or how their
 measurements are distributed.

 I'm not sure if we would use this, but I am writing it down so others can
 decide if they want it, and which option they want.

 '''Quartile Option'''

 This option doesn't tell us the exact range for each relay, but it's easy
 to calculate and understand.

 For each bandwidth authority, and for the measured bandwidth medians:
 * the quartiles of its bandwidth measurements

 This could look like:
 https://consensus-health.torproject.org/#downloadstats

 '''Range Option'''

 This option is more specific, but might be harder to understand and use.

 For each bandwidth authority:
 * the median of the measurements it controls (the relays for which it is
 the median)
 * the median of the next highest measurement where it is the next highest
 measurement
 * the median of the next lowest measurement where it is the next lowest
 measurement

 We should probably use medians for the average, because we really don't
 care about extremes.

 Maybe this could look something like:

 '''Bandwidth Authority Variance'''
 ||  || lower || median || higher ||
 || longclaw || 27887 || 58578  || 89090  ||
 || gabelmoo || 34585 || 69344  || 84323  ||

 Or maybe it would be better to express them as percentages of the median.

--

Comment (by teor):

 It might also be helpful to have quartiles for the overall
 measurements/medians.

--
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] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distribution of a bandwidth authority's measurements? (was: Consensus Health: what is the distrubution of a bandwidth au

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distribution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

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

Re: [tor-bugs] #21993 [Metrics/Consensus Health]: Consensus Health: are an authority's measurements higher or lower than others?

[Tor Bug Tracker & Wiki]

#21993: Consensus Health: are an authority's measurements higher or lower than
others?
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Low   |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

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


Comment:

 This is also a duplicate of #21882.

--
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] #21882 [Metrics/Consensus Health]: Graph for number of relays that bwauths decided the median for

[Tor Bug Tracker & Wiki]

#21882: Graph for number of relays that bwauths decided the median for
--+-
 Reporter:  Sebastian |  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:
--+-

Comment (by teor):

 I had this idea, too, and I opened #21992. I've now closed it as a
 duplicate.

--
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] #21992 [Metrics/Consensus Health]: Consensus Health: how many medians does each bandwidth authority control?

[Tor Bug Tracker & Wiki]

#21992: Consensus Health: how many medians does each bandwidth authority 
control?
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

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


Comment:

 Looks like this is a duplicate of #21882. Oops.

--
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] #21964 [Core Tor/Tor]: Consdiff code accepts non-numbers in ranges

[Tor Bug Tracker & Wiki]

#21964: Consdiff code accepts non-numbers in ranges
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 I think it is sufficient, I addded some more tests demonstrating that. Let
 me know if there's any more tests you think I should add. I pushed a fixup
 commit using TOR_ISDIGIT, thanks for that suggestion.

--
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] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distrubution of a bandwidth authority's measurements?

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distrubution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Old description:

> Once we know how many relays a bandwidth authority controls (#21992), we
> might want to know how much it can change their figures, or how their
> measurements are distributed.
>
> I'm not sure if we would use this, but I am writing it down so others can
> decide if they want it, and which option they want.
>
> '''Quartile Option'''
>
> This option doesn't tell us the exact range for each relay, but it's easy
> to calculate and understand.
>
> For each bandwidth authority:
> * the quartiles of its bandwidth measurements
>
> This could look like:
> https://consensus-health.torproject.org/#downloadstats
>
> '''Range Option'''
>
> This option is more specific, but might be harder to understand and use.
>
> For each bandwidth authority:
> * the median of the measurements it controls
> * the median of the next highest measurement
> * the median of the next lowest measurement
>
> We should probably use medians for the average, because we really don't
> care about extremes.
>
> Maybe this could look something like:
>
> '''Bandwidth Authority Variance'''
> ||  || lower || median || higher ||
> || longclaw || 27887 || 58578  || 89090  ||
> || gabelmoo || 34585 || 69344  || 84323  ||
>
> Or maybe it would be better to express them as percentages of the median.

New description:

 Once we know how many relays a bandwidth authority controls (#21992), we
 might want to know how much it can change their figures, or how their
 measurements are distributed.

 I'm not sure if we would use this, but I am writing it down so others can
 decide if they want it, and which option they want.

 '''Quartile Option'''

 This option doesn't tell us the exact range for each relay, but it's easy
 to calculate and understand.

 For each bandwidth authority:
 * the quartiles of its bandwidth measurements

 This could look like:
 https://consensus-health.torproject.org/#downloadstats

 '''Range Option'''

 This option is more specific, but might be harder to understand and use.

 For each bandwidth authority:
 * the median of the measurements it controls (the relays for which it is
 the median)
 * the median of the next highest measurement where it is the next highest
 measurement
 * the median of the next lowest measurement where it is the next lowest
 measurement

 We should probably use medians for the average, because we really don't
 care about extremes.

 Maybe this could look something like:

 '''Bandwidth Authority Variance'''
 ||  || lower || median || higher ||
 || longclaw || 27887 || 58578  || 89090  ||
 || gabelmoo || 34585 || 69344  || 84323  ||

 Or maybe it would be better to express them as percentages of the median.

--

Comment (by teor):

 I think the range option is very confusing, and we probably just want
 quartiles.

--
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] #21992 [Metrics/Consensus Health]: Consensus Health: how many medians does each bandwidth authority control?

[Tor Bug Tracker & Wiki]

#21992: Consensus Health: how many medians does each bandwidth authority 
control?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When we change the bandwidth authorities, we want to know what impact this
 has on their measurements.

 This matters most for:
 * new bandwidth authorities, and
 * changing the location of bandwidth authorities or bandwidth servers

 It would help us if we knew for each relay:
 * the median bandwidth authority: the bandwidth authority that made the
 relay's median measurement

 This tells us which authority has control over the measurement. One way to
 implement this would be to make the median bold in each relay's bandwidth
 row.

 It would also help us if we knew for each bandwidth authority:
 * how many relays have its measurement as the median

 One way to implement this is to add to the "Bandwidth scanner status"
 table:
 https://consensus-health.torproject.org/#bwauthstatus

 || longclaw || 7845 measured || 1569 median ||
 || gabelmoo || 7419 measured || 1484 median ||

 It would also be helpful to have a graph of how this changes over time.

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

[tor-bugs] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distrubution of a bandwidth authority's measurements?

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distrubution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Once we know how many relays a bandwidth authority controls (#21992), we
 might want to know how much it can change their figures, or how their
 measurements are distributed.

 I'm not sure if we would use this, but I am writing it down so others can
 decide if they want it, and which option they want.

 '''Quartile Option'''

 This option doesn't tell us the exact range for each relay, but it's easy
 to calculate and understand.

 For each bandwidth authority:
 * the quartiles of its bandwidth measurements

 This could look like:
 https://consensus-health.torproject.org/#downloadstats

 '''Range Option'''

 This option is more specific, but might be harder to understand and use.

 For each bandwidth authority:
 * the median of the measurements it controls
 * the median of the next highest measurement
 * the median of the next lowest measurement

 We should probably use medians for the average, because we really don't
 care about extremes.

 Maybe this could look something like:

 '''Bandwidth Authority Variance'''
 ||  || lower || median || higher ||
 || longclaw || 27887 || 58578  || 89090  ||
 || gabelmoo || 34585 || 69344  || 84323  ||

 Or maybe it would be better to express them as percentages of the median.

--
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] #21993 [Metrics/Consensus Health]: Consensus Health: are an authority's measurements higher or lower than others?

[Tor Bug Tracker & Wiki]

#21993: Consensus Health: are an authority's measurements higher or lower than
others?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Once we know how many relays a bandwidth authority controls (#21992), it
 would be useful to know what whether an authority's measurements are
 higher or lower than others.

 For each bandwidth authority:
 * how many relays have its measurement as the next-highest measurement
 * how many relays have its measurement as the next-lowest measurement

 Maybe this could look something like:

 '''Bandwidth Authority Positions'''
 ||  || min  || lower || median || higher || higher || max  ||
 || longclaw || 1200 || 1569  || 1300   || 1000   || 1400   || 1700 ||
 || gabelmoo || 1500 || 1484  || 1100   ||  900   || 1200   || 2890 ||

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