Re: [tor-bugs] #28074 [Internal Services/Service - git]: please add arma to @torproject-admin

[Tor Bug Tracker & Wiki]

#28074: please add arma to @torproject-admin
-+
 Reporter:  weasel   |  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:
-+
Changes (by weasel):

 * status:  needs_revision => new


Old description:

> Please add arma to @torproject-admin in the gitolite config.

New description:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

  Please add arma to @torproject-admin in the gitolite config.
 -BEGIN PGP SIGNATURE-

 iQEzBAEBCAAdFiEEs4PXhajJL968BgN2hgLIIDhyMx8FAlvIH9sACgkQhgLIIDhy
 Mx8mDggAqGxJDEDH2eUKFIrX7SnSxGnQK5PH6uQiBzJsJAjHQ4JwopLPc7lByWd9
 jrcxhbfQAXHYcxbU4YRN9w8l5b1+8HhmWZNCwEnuF/XkBQWKqggA7n9ezHA+Uye4
 IeBXen1GdHs9NVpsN+XozaNCFKyQBjpgmZvve610r5TjuBm133dP9P90BUqV+TDm
 BjFpqrZA+cy6T48I5orqQKTUG691eICBs+P2F6ux//bB9+gZSujsHm8myPnAX6Ug
 FisSUZUZl+r+U7nWadGA2zQE9X83rTOdYSPtU3g7lQKULu9XCFpshcTV54PJB3Ry
 BIq8ktTBeVNlINw9RfXwzZHoGyxiqg==
 =Rx4N
 -END PGP SIGNATURE-
 }}}

--

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

[tor-bugs] #28101 [Internal Services/Tor Sysadmin Team]: Please create short-term email alias for new job posting

[Tor Bug Tracker & Wiki]

#28101: Please create short-term email alias for new job posting
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please create a short-term email alias for our new job posting:

 job-metrics@

 It should be distributed to:

 gaba@
 karsten@
 irl@
 ewyatt@
 isabela@
 teor@
 arma@

 Thank you!
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlvIA2kACgkQugyUAPgP
 kc4xTRAAlfyZlpRjzvvM3L+V0NGzF3FoD53/j3h71iTmTa9Q2zyYDtaEvqjMGxql
 mKwk8HOJKUEEfXRoPbvGqmECS0l8ctuN+LgzFGs4OF9cHz+36B/qIKs3gaS183e5
 KT/Xu/u10x2EyW7vJ57d4pIZDssfGvOvENWrYzIG2ItO9Hl8BGA4BZgJnMkQ2ik1
 twD18lUvAhj+whdeKPvah/XYJR4+uIOQ9jrO6KsbnBERV0IAYRSTqweZ0ajDrhhj
 yEwvTnyd0/rWiMhFpoZEcYPXsN/eagouZKO8NbXC1DjX/Ir0PLr7v5OQsZbv11mD
 eKSzAYFoWtCv/G6TcoqYX5ipY9xovAGXtrAx15I7IVlZgJjie4sDQllJPZgH4Jqh
 2HzCQpFrkRCBWTtU9/+UMOD9l9SBzBdPcMKwlMoboVZqpiWidT9vXo7WiLeaA4it
 V1grj0MUr4MPHasfpu1yA1LcITD1CgzrDc05sWu+oOjzAw5+w1VLqU/orqC8PJtf
 fmrROjaGgwG+ytYdxf2ROzx/4WJyDwMGl8OYnYT3JDyaSBBkVJueFT1LAchmPADI
 SqR4owhPbeaGIu30tbKDZYnU+Jh4xFO/mSITOxLs1nc1O3ILirstUaRxxx7w8Uk+
 7VxM8LoGy8d1ohc2jdyIcezwlpnKf7/ar0H7l5zcH9Ick5eVHOg=
 =d1QO
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #27657 [Applications/Tor Browser]: Show .onion icon on Identity drop down?

[Tor Bug Tracker & Wiki]

#27657: Show .onion icon on Identity drop down?
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Mozilla are somewhat inconsistent in this area with the UI, too. As
 Richard mentioned in [ticket:23247#comment:67 the original ticket], when a
 website is loaded over TLS with active-loaded mixed content, the security
 indicator in the URL bar shows a gray lock icon with a yellow triangle
 overlaid on top of it. However, in the identity dropdown, the lock icon
 does not have the yellow indicator overlaid on top of it (the yellow
 triangle is moved down to the description).

 I think the active-blocked mixed-content security indicator is a good
 example of how we should consider implementing this. The user is shown a
 green lock icon but there is a note in the dropdown mentioning some
 content was blocked (https://mixed-script.badssl.com/). Overall, I think
 we should continue giving the user the same assurance that their
 connection is onion-encrypted. I noticed the inconsistency today, and I
 was admittedly confused because I expected the Identity dropdown would
 show the onion icon, too.

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I rebased to the latest code from trunk. It looks like the current gradle
 build has upgraded the sdk to 26. I made changes to update in android-
 toolchain but the firefox build is still broken. I'll need to investigate
 causes and fix.

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

Re: [tor-bugs] #27438 [Applications/Tor Browser]: Android Gradle Build Downloads

[Tor Bug Tracker & Wiki]

#27438: Android Gradle Build Downloads
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:15 boklm]:
 > Looking at the content of https://github.com/sisbell/tor-android-
 repo/blob/master/download-urls-1.0.txt and the content of the `maven-
 repo-1.0.tar.gz` archive, it seems that the archive simply contains the
 files listed in `download-urls-1.0.txt` in the same directories as the
 URLs. Is there more than that in the process to generate the maven repo?
 If not then it seems to me a little overkill to require a rust program to
 generate that archive.
 >
 > I think we could add sha256sums to the `download-urls-1.0.txt` file, and
 then it would not be very complicate to write a shell script that download
 each file, check its checksum, extract the directory from the URL and move
 the file to that directory. We could then use this script within an `exec`
 of an `input_file`, similarly to what is done in `projects/firefox-
 langpacks/config`.
 >
 > I only looked at the content of `maven-repo-1.0.tar.gz` quickly, so I
 may have missed something. Is there something that I missed in the process
 of generating the maven repo?
 >> Its a little more complicated but not by much. Basically, it checks
 extensions to see if it has gpg signature for an artifact and if so then
 verifies it with a key from key server. If there is no gpg sig, then it
 looks for a sha2 file and verifies that. If there is no sha2, then it just
 generates one and flags it. (it could go on to check sha1, md5 but I
 didn't implement that). I'm ok either way with script or artc. Would that
 require different scripts for each platform we build on?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27438 [Applications/Tor Browser]: Android Gradle Build Downloads

[Tor Bug Tracker & Wiki]

#27438: Android Gradle Build Downloads
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:14 boklm]:
 > For a review of commit `27604107dca4992aac4a2f3b015f5a7c4273a606`:
 > - does `maven-repo-1.0.tar.gz` contains the dependencies that are
 specific to firefox? If so then I think it should be moved to
 `projects/firefox/config` instead of `projects/android-toolchain/config`.
 In the future `android-toolchain` will be used to build other components
 than firefox, such as Tor.
 > > A lot of these artifacts will be duplicated between projects, meaning
 we may be downloading and archiving multiple times. Would that be a
 problem?

 > - the name of the file `README.ANDROID` is a little confusing, as it
 doesn't really talk about android but only about how to generate a maven
 repo archive. Maybe that could be renamed to something like
 `projects/firefox/how-to-generate-maven-repo.txt`?
 >> Sounds good

 > - `curl https://sh.rustup.rs -sSf | sh` does not look like a safe way to
 install rust. Would that work if we just suggested installing the `rustc`
 package from the distribution?
 >> It can be downloaded and used like we do in projects/rust

 > - I don't know much about cargo, but do I understand correctly that
 `cargo install artc` is downloading artc binaries from https://crates.io/?
 If so, is there some way this can be done by building
 https://github.com/sisbell/artc from sources?
 >> crates just has the source and builds from that.
 ~/.cargo/registry/src/artc contains the source. But yes, it can also be
 downloaded directly from git and run.

 > - How was `download-urls-1.0.txt` from https://github.com/sisbell/tor-
 android-repo generated? Maybe we should include that file directly into
 `tor-browser-build` (for instance in the projects/firefox directory)
 instead of storing it in a separate git repo.
 >> I put info on how its generated in the readme file of the tor-android-
 repo. Basically, I just grep the gradle logs and pull out the URLS.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28100 [Core Tor/Tor]: Tor shouldn't set Content-Type: application/octet-stream when compressing results

[Tor Bug Tracker & Wiki]

#28100: Tor shouldn't set Content-Type: application/octet-stream when 
compressing
results
-+--
 Reporter:  Hello71  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 arma complained on IRC about his browser trying to download descriptor
 files instead of displaying them in the browser.

 I tracked this to tor replacing the Content-Type with application/octet-
 stream when compression is done.

 At least in modern HTTP, the Content-Type should not change with
 compression. You can see this by using curl --compressed -v or -I on any
 modern web server. Example:

 {{{
 $ curl --compressed -I https://www.torproject.org
 HTTP/1.1 200 OK
 Date: Thu, 18 Oct 2018 01:48:00 GMT
 Server: Apache
 Content-Location: index.html.en
 Vary: negotiate,Accept-Encoding
 TCN: choice
 X-Content-Type-Options: nosniff
 X-Frame-Options: sameorigin
 X-Xss-Protection: 1
 Referrer-Policy: no-referrer
 Strict-Transport-Security: max-age=15768000; preload
 Content-Security-Policy: default-src 'self'; script-src 'self'; style-src
 'self' 'unsafe-inline';
 Last-Modified: Wed, 17 Oct 2018 18:48:13 GMT
 ETag: "3ca6-578711cc71540-gzip"
 Accept-Ranges: bytes
 Content-Encoding: gzip
 Cache-Control: max-age=3600
 Expires: Thu, 18 Oct 2018 02:48:00 GMT
 Content-Length: 4049
 Content-Type: text/html
 Content-Language: en
 }}}

 I didn't really look hard for any specs. It's probably somewhere in some
 RFC, but as a practical matter, 100% of web servers do this and 100% of
 web clients expect this.

 I'm pretty sure this won't break Tor, since I searched the code for
 "content-type" and didn't find any results actually checking the type,
 only setting it.

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

Re: [tor-bugs] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
-+-
 Reporter:  nickm|  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by Hello71):

 Replying to [comment:4 yawning]:
 > Replying to [comment:3 arma]:
 > > FYI, my wget didn't send any accept-encoding header. Neither did
 Sebastian's. Maybe Yawning's did? You can tell it to *add* an accept-
 encoding header, but then what do you expect.
 >
 > `wget http://example.com` on my system does this:
 >
 > {{{
 > GET / HTTP/1.1
 > User-Agent: Wget/1.19.1 (linux-gnu)
 > Accept: */*
 > Accept-Encoding: identity
 > Host: example.com
 > Connection: Keep-Alive
 > }}}
 >
 > Python's HTTP client also includes the header with `identity`.
 >
 > > I think the issue here is more that there are two ways to indicate you
 want compression -- adding a .z to the url, and saying so in the accept-
 encoding header -- and we should build the two by two decision matrix and
 do the smart thing for all four cases.
 >
 > Yes.  The existing code tries to treat `.z` as `Accept-Encoding:
 deflate`, which is a shortcut, and not always correct.  Assuming we do not
 want to double compress, what I would consider working behavior looks
 like:
 >
 > || File || Accept-Encoding || Action
 ||
 > || `foo`|| N/A || `foo`
 ||
 > || `foo`|| `identity`  || `Content-Encoding: identity`,
 `foo`  ||
 > || `foo`|| `deflate`   || `Content-Encoding: deflate`,
 `deflate(foo)` ||
 > || `foo`|| `identity, deflate` || `Content-Encoding: deflate`,
 `deflate(foo)` ||
 > || `foo`|| `identity, gzip`|| `Content-Encoding: gzip`,
 `gzip(foo)`||
 > || `foo`|| `gzip`  || `Content-Encoding: gzip`,
 `gzip(foo)`||
 > || `foo`|| `deflate, gzip` || `Content-Encoding: gzip`,
 `gzip(foo)`||
 > || `foo.z`  || N/A || `deflate(foo)`
 ||
 > || `foo.z`  || `identity`  || `Content-Encoding: identity`,
 `deflate(foo)` ||
 > || `foo.z`  || `deflate`   || `406 Not Acceptable`
 ||
 > || `foo.z`  || `identity, deflate` || `Content-Encoding: identity`,
 `deflate(foo)` ||
 > || `foo.z`  || `identity, gzip`|| `Content-Encoding: identity`,
 `deflate(foo)` ||
 > || `foo.z`  || `gzip`  || `406 Not Acceptable`
 ||
 > || `foo.z`  || `deflate, gzip` || `406 Not Acceptable`
 ||
 >
 > (`gzip` used as a placeholder algorithm for "Something that is supported
 that is not `deflate`)
 >
 > The current code mishandles the cases in the table that should either
 double compress or return `406`.

 I believe this is not consistent with modern HTTP and web client behavior.
 I am fairly sure that modern web clients do one of the following:

 1. send Accept-Encoding: deflate, gzip (or gzip, deflate)
 2. if the response is Content-Encoding: deflate or gzip, transparently
 decompress it.
 3. process the decompressed content as the type indicated in Content-Type.

 1. do not send Accept-Encoding, or send Accept-Encoding: identity
 2. do not decompress the content
 3. process the content as the type indicated in Content-Type.

 Note that not sending any Accept-Encoding is identical to sending Accept-
 Encoding: identity, as specified in RFC 7231
 (https://tools.ietf.org/html/rfc7231#section-5.3.4).

 I am fairly sure that this behavior also does not depend on the file
 extension of the URL. Therefore, it is not correct to return 406 if the
 server thinks that compressing the content is stupid (note that this is
 not just the case for gzipped files. it also applies to image files, video
 files, font files, and so on; too many for the browser to even attempt to
 make a comprehensive list of file extensions). Instead, it should simply
 not compress the content, not send Content-Encoding: identity, and send it
 as is. You can see this behavior if you execute for example `curl
 --compressed -v torproject.org`. Compression is offered, but the server
 doesn't want to bother, so it just doesn't compress it. This is supported
 by 

Re: [tor-bugs] #25885 [Core Tor/Tor]: count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

[Tor Bug Tracker & Wiki]

#25885: count_acceptable_nodes() would be more accurate using
node_has_preferred_descriptor()
--+
 Reporter:  nickm |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I have made the changes and pushed it. Same branch/PR.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28062 [Core Tor/sbws]: Publish bandwidth files only when they contain only the 60% of relays

[Tor Bug Tracker & Wiki]

#28062: Publish bandwidth files only when they contain only the 60% of relays
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Based on the comments in #28042, I think we need to implement #28076,
 where we create a file with a header but no relays.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 Replying to [comment:6 juga]:
 > Replying to [comment:4 teor]:
 > > I am very confused by these results. It seems strange to me that sbws
 can't make 2 measurements of a relay over a few days.
 >
 > It also seems weird to me, so that i've been debugging prioritization
 today, so far i didn't find the reason.

 Is there some documentation for relay priority?
 If we prioritise failed relays, then most of our circuits will fail. In
 some cases, we will overload relays that are already failing.

 > > Can you please tell us:
 > > * how long sbws has been running for?
 >
 > Forever :) Results dated older than 7 days ago are not took
 > Those results were done without the last recent day, but still.
 >
 > > * the number of relays measured each day:
 >
 > This is the number of results each day, not relays:
 >
 > 1555 2018-10-10.txt
 > 1485 2018-10-11.txt
 > 1363 2018-10-12.txt
 > 1574 2018-10-13.txt
 > 1665 2018-10-14.txt

 If it takes 5 days for sbws to measure 7000 relays, then maybe sbws should
 use results from the last 10 days.

 > 1707 2018-10-15.txt
 > 1819 2018-10-16.txt
 > 3332 2018-10-17.txt

 ...

 > > * the exact code that you are using to do the "2 measurements at least
 24 hours apart" test?
 >
 > https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py#n278

 Ok, so there is a bug in this code.

 The original task was:

 > If any of these things are true, do not put the relay in the bandwidth
 file:
 > * there are less than 2 sbws measured bandwidths
 > * all the sbws measured bandwidths are within 24 hours of each other

 But the code implements:

 1. If there are less than 2 results, do not put the relay in the bandwidth
 file
 2. If any result is within 24 hours of the previous result, remove it.
 Then, if there is only one result, do not put the relay in the bandwidth
 file.

 Here are some results and the outputs they should produce:
 0h produces None
 0h, 24h produces 0h, 24h
 0h, 1h, 24h produces 0h, 1h, 24h (but I think the current function
 produces 0h, 24h)
 0h, 24h, 36h produces 0h, 24h, 36h (but I think the current function
 produces 0h, 24h)

 Maybe these functions need some unit tests?

 > > * the exact measurement times for a relay that passes the test?
 >
 > Attachment

 I don't understand this attachment.
 It looks like a list of all the times that pass the test, with no relay
 ids.

 But I wanted to see a list of times for one relay that passes the test.

 > > * the exact measurement times for a relay with multiple measurements
 that fails the test?
 >
 > Attachment
 > All from today, hmm?

 Let's just focus on a single relay.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:1 juga]:
 > Maybe we should not include any scaling method, and instead create a
 bandwidth scaling specification when we come out with an algorithm that is
 tested enough we are happy with.

 We should delete the parts of the spec that we aren't going to implement
 soon.

 > Otherwise, should we include/repeat Torflow scaling in this spec?

 Yes, because eventually we will delete the torflow repository and spec.
 Also, torflow's scaling spec is hard to find, and it is buried in a whole
 lot of other specs for code that is not used.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28099 [Core Tor/sbws]: Make a policy for adding new sbws relay keys

[Tor Bug Tracker & Wiki]

#28099: Make a policy for adding new sbws relay keys
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Split from #28085:
 > I think we should also come up with some policy to add/remove
 key/values.
 > Even if all the ones we have so far seem useful, we are not using it.

 I don't understand. Do you mean:

 There are some keys in the spec that are not in the code.
 Or
 There are some keys in the code that are not in the spec.
 Or
 There are some keys in the spec and the code that are not being used by
 anyone.

 > For instance, do we have tickets of cases where these key/values were
 needed/requested?.

 When we find this information, we should update the spec so it tells us
 why we need each value.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 Replying to [ticket:28085 juga]:
 > To scale as Torflow, it was added `relay_observed_bandwidth` and
 `relay_average_bandwidth`.

 We document the keys and values in the spec, so we know what they mean.
 So we need to add these keys to the spec.

 > I think we should also come up with some policy to add/remove
 key/values.

 I answered in a new ticket #28099, because a policy is a different issue
 to a spec update.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27471 [Core Tor/Tor]: HS intermittently fails: Non-fatal assertion failed in send_introduce1

[Tor Bug Tracker & Wiki]

#27471: HS intermittently fails: Non-fatal assertion failed in send_introduce1
---+---
 Reporter:  tgragnato  |  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.4.7-rc
 Severity:  Minor  | Resolution:
 Keywords:  tor-hs, regression?, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
---+---

Comment (by asn):

 Replying to [comment:15 dgoulet]:
 > Replying to [comment:14 asn]:
 > > ACK on the above.
 > >
 > > To simplify your patch, would it be possible to unify
 `circuit_get_next_client_intro_circ()` and
 `circuit_get_next_service_intro_circ()` to reduce duplicate code?
 >
 > Doable.
 >
 > >
 > > If we do that I think we can get this merged and see if this thing
 ever appears again.
 >
 > H wait, you want the close all circuits or the lets reextend on
 error?

 Please check my branch `ticket27471_035_01` and PR:
 https://github.com/torproject/tor/pull/414

 I went with your approach of closing all open circuits, plus I added a
 fixup that unifies the two "get_intro_circ" functions into one.

 If you like it, let's squash it and put it in merge_ready. If you don't
 like it, we can put your branch into merge_ready.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28098 [- Select a component]: Tor not reopening on USB

[Tor Bug Tracker & Wiki]

#28098: Tor not reopening on USB
--+--
 Reporter:  mackey|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:  usb   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I tried opening tor again (through USB) after I initially connected the
 first time (which worked fine on the USB). It just opened firefox and no
 connection window showed before that loaded. It works fine if I install
 directly to my Windows 10 drive (c:/). I am using Windows 10 with Tor
 version 8.02.

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.1
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Reported by Keifer Bly:
 https://lists.torproject.org/pipermail/tor-relays/2018-October/016466.html

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.1
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  windows, fast-fix =>
 windows, fast-fix, 029-backport, 033-backport, 034-backport,
 035-backport
 * actualpoints:   => 0.1


Comment:

 I opened #28097 to get a more accurate version.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28097 [Core Tor/Tor]: Get the actual Windows version from Kernel32.dll

[Tor Bug Tracker & Wiki]

#28097: Get the actual Windows version from Kernel32.dll
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  windows
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Windows 8.1 and later pretend to be Windows 8 (#28096).

 If we want to display the real Windows version, we can use
 GetFileVersionInfo() to check the version of Kernel32.dll:
 https://docs.microsoft.com/en-au/windows/desktop/SysInfo/getting-the-
 system-version

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  windows, fast-fix
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In Windows 8.1, Microsoft changed the behaviour of the GetVersionEx
 function so that it returns 6.2 (Windows 8) for applications without a
 compatibility manifest. (For applications with a compatibility manifest,
 it returns the version in that manifest.)

 https://docs.microsoft.com/en-au/windows/desktop/api/sysinfoapi/nf-
 sysinfoapi-getversionexa

 We should change the version returned by Tor's uname function to "Windows
 8 or later".

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

Re: [tor-bugs] #28074 [Internal Services/Service - git]: please add arma to @torproject-admin

[Tor Bug Tracker & Wiki]

#28074: please add arma to @torproject-admin
-+-
 Reporter:  weasel   |  Owner:  tor-gitadm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 A temporary membership has been granted to allow pili's LDAP account to be
 created.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28074 [Internal Services/Service - git]: please add arma to @torproject-admin

[Tor Bug Tracker & Wiki]

#28074: please add arma to @torproject-admin
-+-
 Reporter:  weasel   |  Owner:  tor-gitadm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * status:  new => needs_revision


Comment:

 weasel, the docs at
 
https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure/git.torproject.org#Addingdeveloperstoarepository
 say "This should be GPG signed as above."

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27438 [Applications/Tor Browser]: Android Gradle Build Downloads

[Tor Bug Tracker & Wiki]

#27438: Android Gradle Build Downloads
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Looking at the content of https://github.com/sisbell/tor-android-
 repo/blob/master/download-urls-1.0.txt and the content of the `maven-
 repo-1.0.tar.gz` archive, it seems that the archive simply contains the
 files listed in `download-urls-1.0.txt` in the same directories as the
 URLs. Is there more than that in the process to generate the maven repo?
 If not then it seems to me a little overkill to require a rust program to
 generate that archive.

 I think we could add sha256sums to the `download-urls-1.0.txt` file, and
 then it would not be very complicate to write a shell script that download
 each file, check its checksum, extract the directory from the URL and move
 the file to that directory. We could then use this script within an `exec`
 of an `input_file`, similarly to what is done in `projects/firefox-
 langpacks/config`.

 I only looked at the content of `maven-repo-1.0.tar.gz` quickly, so I may
 have missed something. Is there something that I missed in the process of
 generating the maven repo?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28078 [Core Tor/Nyx]: nyx hangs (sometimes) when tor process vanishes

[Tor Bug Tracker & Wiki]

#28078: nyx hangs (sometimes) when tor process vanishes
--+---
 Reporter:  traumschule   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 Personally I never use pdb, but the hanging shouldn't matter to the log.
 If we're lucky the messages emitted before and when nyx hangs should
 hopefully give a clue about where I buggered up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27438 [Applications/Tor Browser]: Android Gradle Build Downloads

[Tor Bug Tracker & Wiki]

#27438: Android Gradle Build Downloads
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  new => needs_revision


Comment:

 For a review of commit `27604107dca4992aac4a2f3b015f5a7c4273a606`:
 - does `maven-repo-1.0.tar.gz` contains the dependencies that are specific
 to firefox? If so then I think it should be moved to
 `projects/firefox/config` instead of `projects/android-toolchain/config`.
 In the future `android-toolchain` will be used to build other components
 than firefox, such as Tor.
 - the name of the file `README.ANDROID` is a little confusing, as it
 doesn't really talk about android but only about how to generate a maven
 repo archive. Maybe that could be renamed to something like
 `projects/firefox/how-to-generate-maven-repo.txt`?
 - `curl https://sh.rustup.rs -sSf | sh` does not look like a safe way to
 install rust. Would that work if we just suggested installing the `rustc`
 package from the distribution?
 - I don't know much about cargo, but do I understand correctly that `cargo
 install artc` is downloading artc binaries from https://crates.io/? If so,
 is there some way this can be done by building
 https://github.com/sisbell/artc from sources?
 - How was `download-urls-1.0.txt` from https://github.com/sisbell/tor-
 android-repo generated? Maybe we should include that file directly into
 `tor-browser-build` (for instance in the projects/firefox directory)
 instead of storing it in a separate git repo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * cc: neel (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] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  new => assigned
 * owner:  (none) => neel


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27441 [Applications/Tor Browser]: Update Debian Image to use Stretch

[Tor Bug Tracker & Wiki]

#27441: Update Debian Image to use Stretch
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 In commit `7d14d1b96aaf5c5718fdf9ed6ad8986abfa6902d` the trailing white
 space is removed, but now there is a typo: `ha256sum` instead of
 `sha256sum`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27441 [Applications/Tor Browser]: Update Debian Image to use Stretch

[Tor Bug Tracker & Wiki]

#27441: Update Debian Image to use Stretch
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:13 boklm]:

 > Replying to [comment:12 sisbell]:
 >
 >
 >
 > > Removed trailing white space: https://github.com/sisbell/tor-browser-
 build/commits/android-1017
 > >
 > >
 > >
 >
 > In commit `9f90042f71ec8d509c7beb5e9efeb97a8390aa3a` from the
 `android-1017` branch, I still see a trailing white space after the
 sha256sum. Actually the commit is the same in the `android-rebased` and
 the `android-1017` branch.
 > > Fixed, try 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] #27907 [Core Tor/Tor]: PrivCount config and version spec

[Tor Bug Tracker & Wiki]

#27907: PrivCount config and version spec
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  needs-proposal, privcount  |  Actual Points:
Parent ID:  #25153 | Points:
 Reviewer: |Sponsor:  SponsorV
---+--
Changes (by gaba):

 * sponsor:   => SponsorV


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27438 [Applications/Tor Browser]: Android Gradle Build Downloads

[Tor Bug Tracker & Wiki]

#27438: Android Gradle Build Downloads
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:12 boklm]:
 > Replying to [comment:8 boklm]:
 > > I think we can start with (1), generating a tar file independently and
 uploading it somewhere. Then we can see later if we can integrate it
 better.
 >
 > We should also have a comment near the tar file URL explaining how that
 archive was generated.

 I've added this comment. If it looks good, I think we can close this issue

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26697 [Applications/Tor Browser]: Add Android toolchain

[Tor Bug Tracker & Wiki]

#26697: Add Android toolchain
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Updated:

  * Added README.ANDROID file that explains how to build the maven repo.
 Added comment in android-toolchain/config that references the readme file.


  * Changed the name of the repo to include a version: maven-
 repo-1.0.tar.gz


  * Removed trailing whitespaces


  * Created git repo for download artifact list: https://github.com/sisbell
 /tor-android-repo



 Changes are on android-1017 branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28095 [Core Tor/Tor]: dirauth key pinning can be bypassed sometimes?

[Tor Bug Tracker & Wiki]

#28095: dirauth key pinning can be bypassed sometimes?
--+--
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-dirauth
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 It looks like sometimes key pinning can be bypassed.  One example is in
 #27800, where it seems that an ed25519 key got shared between two relays
 (Or maybe that's two iterations of the same relay,  where the operator
 rolled the RSA key but not the ed25519 key.)

 Fixing this the "right" way might involve keeping multiple versions of a
 relay descriptor around,  with metadata about which vote or consensus it
 goes with.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28078 [Core Tor/Nyx]: nyx hangs (sometimes) when tor process vanishes

[Tor Bug Tracker & Wiki]

#28078: nyx hangs (sometimes) when tor process vanishes
--+---
 Reporter:  traumschule   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * status:  new => needs_information


Comment:

 yes! should have done this from the beginning. Now i start it with {{{pdb
 ./run_nyx -d nyx-system-tor.log}}} but i wonder what will happen when nyx
 hangs again, since it's in the same window i won't have a chance to
 interact with pdb i guess, the log may help still.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27800 [Core Tor/Tor]: Non-fatal assertion !(old) failed in node_add_to_ed25519_map

[Tor Bug Tracker & Wiki]

#27800: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
--+
 Reporter:  stefani   |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 035-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  assigned => 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] #27800 [Core Tor/Tor]: Non-fatal assertion !(old) failed in node_add_to_ed25519_map

[Tor Bug Tracker & Wiki]

#27800: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
--+
 Reporter:  stefani   |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 035-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 pull requests:

 [https://github.com/torproject/tor/pull/412 033]
 [https://github.com/torproject/tor/pull/413 035]

 The 033 one merges cleanly into 034.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28078 [Core Tor/Nyx]: nyx hangs (sometimes) when tor process vanishes

[Tor Bug Tracker & Wiki]

#28078: nyx hangs (sometimes) when tor process vanishes
--+
 Reporter:  traumschule   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Hi traumschule, would you mind adding the '--debug' argument to Nyx? That
 will generate a trace level request/reply log with your tor process.
 Hopefully that'll give a bit more of a hint on where we're hanging.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28094 [Core Tor/Tor]: fix docs

[Tor Bug Tracker & Wiki]

#28094: fix docs
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-docs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cyberpunks):

 https://gitgud.io/onionk/tor/compare/master...evdoc-fix1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28094 [Core Tor/Tor]: fix docs

[Tor Bug Tracker & Wiki]

#28094: fix docs
+--
 Reporter:  cyberpunks  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  |   Severity:  Normal
 Keywords:  tor-docs|  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] #27544 [Core Tor/Tor]: hs-v3: Client authorization fixes and improvements post-merge

[Tor Bug Tracker & Wiki]

#27544: hs-v3: Client authorization fixes and improvements post-merge
--+--
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified


Comment:

 Two child in `merge_ready` for 035. The last one is in Unspecified so
 moving this parent ticket out of 035.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27896 [Core Tor/Tor]: base32 padding inconsistency between client and server in HS v3 client auth preview

[Tor Bug Tracker & Wiki]

#27896: base32 padding inconsistency between client and server in HS v3 client 
auth
preview
--+
 Reporter:  jchevali  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information
 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified


Comment:

 Replying to [ticket:27896 jchevali]:
 > There seems to be some base32 padding tolerance inconsistency between
 client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
 >
 > The server seems to accept base32-encoded client public keys padded with
 = signs to 56 characters in length and won't work otherwise (i.e., if =
 signs are removed).

 I don't think that is accurate. Service side we explicitly do not allow
 padded base32. If the client key line is not equal to the *no padding*
 length, we don't accept.

 {{{
   if (strlen(pubkey_b32) != BASE32_NOPAD_LEN(CURVE25519_PUBKEY_LEN)) {
 log_warn(LD_REND, "Client authorization encoded base32 public key "
   "length is invalid: %s", pubkey_b32);
 goto err;
   }
 }}}

 > while the client would work without the padding (i.e., = signs removed)
 but will ignore the client's private key if the padding is present.

 And the client code does exactly the same:

 {{{
   if (strlen(seckey_b32) != BASE32_NOPAD_LEN(CURVE25519_PUBKEY_LEN)) {
 log_warn(LD_REND, "Client authorization encoded base32 private key "
   "length is invalid: %s", seckey_b32);
 goto err;
   }
 }}}

 >
 > I don't think this affects how the feature works (which I haven't been
 able to test anyway because it doesn't seem to enforce authorization at
 this stage - it still seems to let everyone in), but at least it seems to
 affect which values are valid and allowed to be loaded when reading the
 config.

 Can you explain how you came down to this conclusion? And also, why are
 you saying it is "not enforced"? If the service is configured to use
 client authorization and a client is configured for it, it should NOT let
 everyone go through.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27549 [Core Tor/Tor]: hs-v3: Refactor the descriptor cookie computation code

[Tor Bug Tracker & Wiki]

#27549: hs-v3: Refactor the descriptor cookie computation code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, hs-auth, refactoring  |  Actual Points:
Parent ID:  #27544| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 lgtm. I've cherry pick the fixup:

 Branch: `ticket27549_035_01`
 PR: ​https://github.com/torproject/tor/pull/355

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27549 [Core Tor/Tor]: hs-v3: Refactor the descriptor cookie computation code

[Tor Bug Tracker & Wiki]

#27549: hs-v3: Refactor the descriptor cookie computation code
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, hs-auth, refactoring  |  Actual Points:
Parent ID:  #27544| Points:
 Reviewer:  asn   |Sponsor:
--+

Comment (by dgoulet):

 lgtm;

 We'll need a PR here asn if you can push one?

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

Re: [tor-bugs] #14744 [Applications/GetTor]: Automate upload of latest Tor Browser to cloud services

[Tor Bug Tracker & Wiki]

#14744: Automate upload of latest Tor Browser to cloud services
-+--
 Reporter:  ilv  |  Owner:  ilv
 Type:  defect   | Status:  reopened
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by boklm):

 * cc: boklm (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] #28066 [Core Tor/Tor]: Fix typo in hs_cell_parse_introduce2() comment

[Tor Bug Tracker & Wiki]

#28066: Fix typo in hs_cell_parse_introduce2() comment
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


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

Re: [tor-bugs] #27471 [Core Tor/Tor]: HS intermittently fails: Non-fatal assertion failed in send_introduce1

[Tor Bug Tracker & Wiki]

#27471: HS intermittently fails: Non-fatal assertion failed in send_introduce1
---+---
 Reporter:  tgragnato  |  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  Very High  |  Milestone:  Tor:
   |  0.3.5.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.4.7-rc
 Severity:  Minor  | Resolution:
 Keywords:  tor-hs, regression?, 035-must  |  Actual Points:
Parent ID: | Points:
 Reviewer:  asn|Sponsor:
---+---

Comment (by dgoulet):

 Replying to [comment:14 asn]:
 > ACK on the above.
 >
 > To simplify your patch, would it be possible to unify
 `circuit_get_next_client_intro_circ()` and
 `circuit_get_next_service_intro_circ()` to reduce duplicate code?

 Doable.

 >
 > If we do that I think we can get this merged and see if this thing ever
 appears again.

 H wait, you want the close all circuits or the lets reextend on error?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Replying to [comment:5 pastly]:
 > In case it helps.
 >
 > I've been running sbws from home for just over 24 hours.
 > [...]
 > Months ago when I ran sbws I would see ~80% success measurement rate.
 The < 50% success rate is very concerning to me. That was probably with
 different parameters, and was definitely on a different machine than my
 home desktop. So I will now begin to run it on a server instead.

 I'm running it in a server, i get ~80% success.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * Attachment "donotcount" 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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * Attachment "count" 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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 Replying to [comment:4 teor]:
 > I am very confused by these results. It seems strange to me that sbws
 can't make 2 measurements of a relay over a few days.

 It also seems weird to me, so that i've been debugging prioritization
 today, so far i didn't find the reason.

 > Can you please tell us:
 > * how long sbws has been running for?

 Forever :) Results dated older than 7 days ago are not took
 Those results were done without the last recent day, but still.

 > * the number of relays measured each day:

 This is the number of results each day, not relays:

 1555 2018-10-10.txt
 1485 2018-10-11.txt
 1363 2018-10-12.txt
 1574 2018-10-13.txt
 1665 2018-10-14.txt
 1707 2018-10-15.txt
 1819 2018-10-16.txt
 3332 2018-10-17.txt

 The 2018-10-16 around 14h i increased the number of threads, what does not
 seem to increase the speed too much, probably because of
 https://gitweb.torproject.org/sbws.git/tree/sbws/core/scanner.py#n358

 Today, around 14h, i have commented the rtt measurements. By the number of
 results in the file today, it seems faster now...
 I also noticed that today every prioritization loop (~300 relays) happens
 every ~45min. The days before, it was happening every 6h.
 I still don't understand why such a difference eliminating that code.

 With the data from today, now i get:
 - number of  successfully measured relays with the restriction: 1319
 - number of measured relays: 5933

 > * the exact code that you are using to do the "2 measurements at least
 24 hours apart" test?

 https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py#n278

 > * the exact measurement times for a relay that passes the test?

 Attachment

 > * the exact measurement times for a relay with multiple measurements
 that fails the test?

 Attachment
 All from today, hmm?

 * Today, number of relays with 1 result: 4610, with 2: 1308, with 3: 15

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27827 [Obfuscation/Snowflake]: Reproducibility issue of the snowflake osx64 build

[Tor Bug Tracker & Wiki]

#27827: Reproducibility issue of the snowflake osx64 build
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Obfuscation/Snowflake   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201810R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201810 => tbb-rbm,
   TorBrowserTeam201810R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28093 [Applications/Tor Browser]: 2018 Tor Browser Android donation banner

[Tor Bug Tracker & Wiki]

#28093: 2018 Tor Browser Android donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fundraising, ux-team,|  Actual Points:
  TorBrowserTeam201810, tbb-mobile   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: GeKo (removed)
 * cc: gk (added)
 * keywords:  tbb-fundraising, ux-team => tbb-fundraising, ux-team,
 TorBrowserTeam201810, tbb-mobile


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28091 [Applications/GetTor]: Refactor GetTor to python3

[Tor Bug Tracker & Wiki]

#28091: Refactor GetTor to python3
-+--
 Reporter:  traumschule  |  Owner:  traumschule
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 https://github.com/TheTorProject/gettor/pull/23

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28059 [Applications/Tor Browser]: How to enable add-ons in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28059: How to enable add-ons in Tor Browser for Android
--+---
 Reporter:  Legion|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Legion):

 If it's a bug, my apologies.

 But there IS a solution in !about:config - a few months ago I asked the
 question on the Tor sub in Reddit, and a chap answered with the correct
 setting to enable add-ons. I subsequently deleted the post thinking that's
 the end of the matter, but I now have a new impossible-to-root Tablet, so
 I can't transfer app data (Titanium), and I've forgotten the setting.

 As to your question: "error - software instillation has been disabled by
 your system administrator" - this is the popup at every attempt to install
 an add-on.

 Tor developers know the setting in !about:config to enable add-ons.
 There's been several updates to the app since I first encountered the
 problem on my phone, so either devs are completely unaware of the 'bug' or
 they're happy to let things continue as they are. Whatever the reason, I'd
 like to know this particular setting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28093 [Applications/Tor Browser]: 2018 Tor Browser Android donation banner

[Tor Bug Tracker & Wiki]

#28093: 2018 Tor Browser Android donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-fundraising, ux-
 Severity:  Normal   |  team
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #23925 we are implementing a donation banner for the YE 2018 campaign.
 It would be great to have a donation banner for Tor Browser Android as
 well. We already have the text in
 
https://gitweb.torproject.org/torbutton.git/tree/src/chrome/locale/en/aboutTor.dtd#n30
 getting translated.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26630 [Core Tor/Tor]: Profile-driven work to reduce memory usage, focusing on clients and mobile.

[Tor Bug Tracker & Wiki]

#26630: Profile-driven work to reduce memory usage, focusing on clients and 
mobile.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19-must
-+-
Changes (by gaba):

 * sponsor:  Sponsor8-must => Sponsor19-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21814 [Core Tor/Tor]: Reduce binary size for client-only tor

[Tor Bug Tracker & Wiki]

#21814: Reduce binary size for client-only tor
-+-
 Reporter:  arthuredelstein  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328, 035-roadmap-subticket,   |
  035-triaged-in-20180711|
Parent ID:  #26630   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by gaba):

 * sponsor:  Sponsor8-can => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27800 [Core Tor/Tor]: Non-fatal assertion !(old) failed in node_add_to_ed25519_map

[Tor Bug Tracker & Wiki]

#27800: Non-fatal assertion !(old) failed in node_add_to_ed25519_map
--+
 Reporter:  stefani   |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 035-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 It looks like only direct uploads to authorities update key pinning.
 Downloads of missing descriptors from votes seem to go through the same
 code paths that clients use, so they bypass key pinning.  Thanks to arma
 for helping to confirm this.

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

Re: [tor-bugs] #25593 [Obfuscation/Snowflake]: Broker needs better resilience against DoS

[Tor Bug Tracker & Wiki]

#25593: Broker needs better resilience against DoS
---+---
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by gaba):

 * sponsor:   => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25483 [Obfuscation/Snowflake]: Windows reproducible build of snowflake

[Tor Bug Tracker & Wiki]

#25483: Windows reproducible build of snowflake
---+---
 Reporter:  arlolra|  Owner:  sukhbir
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201805   |  Actual Points:
Parent ID:  #19001 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by gaba):

 * sponsor:   => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27908 [Core Tor/Tor]: PrivCount proof of concept with existing statistics

[Tor Bug Tracker & Wiki]

#27908: PrivCount proof of concept with existing statistics
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  privcount |  Actual Points:
Parent ID:  #22898| Points:
 Reviewer:|Sponsor:  SponsorV
--+
Changes (by gaba):

 * keywords:   => privcount


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27906 [Core Tor/Tor]: PrivCount noise specification

[Tor Bug Tracker & Wiki]

#27906: PrivCount noise specification
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.6.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  needs-proposal, privcount  |  Actual Points:
Parent ID:  #25153 | Points:
 Reviewer: |Sponsor:  SponsorV
---+---
Changes (by gaba):

 * sponsor:   => SponsorV


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27908 [Core Tor/Tor]: PrivCount proof of concept with existing statistics

[Tor Bug Tracker & Wiki]

#27908: PrivCount proof of concept with existing statistics
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22898| Points:
 Reviewer:|Sponsor:  SponsorV
--+
Changes (by gaba):

 * sponsor:   => SponsorV


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28070 [Applications/Tor Browser]: 'Save Image' crashes browser

[Tor Bug Tracker & Wiki]

#28070: 'Save Image' crashes browser
--+---
 Reporter:  babs4 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by babs4):

 Ok here goes-

 In order to 'fix' the crashes-on-startup behavior I had to reset the app
 by clearing data from Android settings. I just now tried to reproduce the
 defect by

 1. Navigating to https://en.m.wikipedia.org/wiki/Main_Page
 2. Long pressing a displayed image (a polar bear in this case)
 3. Tapping the 'Image' tab of the popup menu
 4. Tapping 'Save Image'

 Nothing happened: no crash, no notification, nothing saved to my internal
 storage AFAICT.

 So I then tried to navigate directly to a .jpg file,

 https://upload.wikimedia.org/wikipedia/commons/6/66/Polar_Bear_-
 _Alaska_%28cropped%29.jpg

 , and then following the above steps 2 through 4. Same result (nothing).

 There was no 'Browser' error message or dialog when the original defect
 occurred. Only an 'Android' notification that the Tor Browser Alpha app
 had closed.


 I am running a carrier build of Android 7.1.1 on a Qualcomm ARMv7 Quad-
 core.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23703 [Applications/GetTor]: The Readme.md of Tor Browser Bundle mirror on Github is not correctly updated

[Tor Bug Tracker & Wiki]

#23703: The Readme.md of Tor Browser Bundle mirror on Github is not correctly
updated
-+-
 Reporter:  cypherpunks  |  Owner:  hellais
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  github mirror|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

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


Comment:

 That's great! (Guess we are ok closing this for now.)

 tbb-team: Is it ok for you to open a new ticket to update GetTor on future
 releases or what would be the best way to keep track?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23925 [Applications/Tor Browser]: 2018 Tor Browser donation banner

[Tor Bug Tracker & Wiki]

#23925: 2018 Tor Browser donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fundraising, ux-team,|  Actual Points:
  TorBrowserTeam201810R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-fundraising, ux-team, TorBrowserTeam201810 => tbb-
 fundraising, ux-team, TorBrowserTeam201810R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23925 [Applications/Tor Browser]: 2018 Tor Browser donation banner

[Tor Bug Tracker & Wiki]

#23925: 2018 Tor Browser donation banner
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fundraising, ux-team,|  Actual Points:
  TorBrowserTeam201810   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:9 gk]:
 > Replying to [comment:4 gk]:
 > > 3) I think the user should at least be able to be aware about what is
 happening *before* they click on the button that leads them to the
 donation page. Maybe showing the URL they are about to go to would be a
 good step in that direction.
 >
 > We did so at least last year and I think we should show the URL, which a
 user is about to go to, again if they are hovering over the button.

 Good idea and thanks for the review. I should note that I am not including
 the locale in the URL in this banner, because it occurred to me that we
 are in general promising users not to reveal their locale if they choose
 to spoof `navigator.language`. However, the donate page will still show
 the right locale if the user is not spoofing. So the only thing our URL is
 revealing is which text the user clicked on, which I think doesn't reveal
 much about individual users.

 Here's my revised patch:

 https://github.com/arthuredelstein/torbutton/commit/23925+1

 This version shows the URL in the status bar when the user hovers over the
 button (because the button is now an `` element). In this revision I
 have also added cyan highlighting over part of Line 2 as designed by
 Antonela in https://marvelapp.com/a131e34/screen/48876402.

 Here are a couple of example screenshots:
 * https://arthuredelstein.net/banner_v3_libertad.png
 * https://arthuredelstein.net/banner_v3_farsi.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18750 [Applications/GetTor]: Can you please enable OTR for your XMPP account?

[Tor Bug Tracker & Wiki]

#18750: Can you please enable OTR for your XMPP account?
---+-
 Reporter:  geeyourhairsmellsterrific  |  Owner:  ilv
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Applications/GetTor|Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by traumschule):

 Both! Filed #28092 for OMEMO.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28092 [Applications/GetTor]: Gettor: offer OMEMO encryption for XMPP

[Tor Bug Tracker & Wiki]

#28092: Gettor: offer OMEMO encryption for XMPP
-+
 Reporter:  traumschule  |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #18750
   Points:   |   Reviewer:
  Sponsor:   |
-+
 This was asked for in comment:3:ticket:18750. OMEMO is not as widely
 adopted sa OTR but it may be good to enable both:
 ​https://conversations.im/omemo/
 https://omemo.top/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23072 [Applications/GetTor]: XMPP bot not working

[Tor Bug Tracker & Wiki]

#23072: XMPP bot not working
-+-
 Reporter:  ilv  |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #18750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by traumschule):

 Thanks, i was mislead by #18750. Still i did not receive any answer
 except:
 > riseup.net: For security reasons, encryption is STRONGLY recommended for
 conversations on this 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

Re: [tor-bugs] #28089 [Core Tor/Tor]: Exhausting our bandwidth write limit stops the connection from reading

[Tor Bug Tracker & Wiki]

#28089: Exhausting our bandwidth write limit stops the connection from reading
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  regression, tor-relay, 034-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 (Well hunted!)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28089 [Core Tor/Tor]: Exhausting our bandwidth write limit stops the connection from reading

[Tor Bug Tracker & Wiki]

#28089: Exhausting our bandwidth write limit stops the connection from reading
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  regression, tor-relay, 034-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Merged to 0.3.4 and forward.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28091 [Applications/GetTor]: Refactor GetTor to python3

[Tor Bug Tracker & Wiki]

#28091: Refactor GetTor to python3
-+-
 Reporter:  traumschule  |  Owner:  traumschule
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 It's good to be ahead of time refactoring GetTor to python3.
 https://docs.python.org/2/library/2to3.html#to3-reference

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27827 [Obfuscation/Snowflake]: Reproducibility issue of the snowflake osx64 build

[Tor Bug Tracker & Wiki]

#27827: Reproducibility issue of the snowflake osx64 build
---+--
 Reporter:  boklm  |  Owner:  tbb-team
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  assigned => needs_review


Comment:

 I have a mostly working branch [https://gitweb.torproject.org/user/dcf
 /tor-browser-
 build.git/commit/?h=bug_27827=f92f149ea8ffb9dd64a798453c85aa124a9391aa
 bug_27827].

 It updates to go1.11.1. This update removed all the `/tmp/go-
 build0` paths that we previously had to overwrite. However it left
 a single `/tmp/go-link-0/go.o` path. This path was also affecting
 the Go build ID (a hash of the build inputs), so it couldn't be fixed just
 by overwriting. However, I found a `-tmpdir` flag that lets us replace the
 random path with a static path, and that fixed it.

 There is still a reproducibility problem, which is the gzip timestamp
 (bytes 4, 5, 6, 7) in the tar.gz output file differ across builds. I.e.,
 the complete diffoscope output is
 {{{
 --- bug_27827/tmpdir/snowflake.tar.gz.1
 +++ bug_27827/tmpdir/snowflake.tar.gz.2
 ├── metadata
 │ @@ -1 +1 @@
 │ -gzip compressed data, last modified: Wed Oct 17 16:30:51 2018, from
 Unix
 │ +gzip compressed data, last modified: Wed Oct 17 16:34:52 2018, from
 Unix
 }}}
 I'm guessing that this is some other problem unrelated to go or snowflake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #7028 [Core Tor/Tor]: Implement Adaptive Padding or some variant and measure overhead vs accuracy

[Tor Bug Tracker & Wiki]

#7028: Implement Adaptive Padding or some variant and measure overhead vs 
accuracy
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  SponsorZ, research-needed, tor-  |  Actual Points:
  relay, mike-can term-project research-program  |
  traffic-analysis   |
Parent ID:  #7027| Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by gaba):

 * sponsor:   => Sponsor2


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23072 [Applications/GetTor]: XMPP bot not working

[Tor Bug Tracker & Wiki]

#23072: XMPP bot not working
-+-
 Reporter:  ilv  |  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #18750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mrphs):

 Replying to this ticket as I was pinged on IRC...
 {{{
 10:39 < traumschule> sukhe: mrphs: do you know what needs to be done to
 start the gettor XMPP bot? #23072
 }}}
 Replying to [comment:1 traumschule]:
 > Trying to add get_tor at riseup.net or send messages failed.

 The actual address for the GetTor XMPP bot is get...@torproject.org as
 documented on https://gettor.torproject.org

 That being said, I don't currently have an XMPP client handy to test
 things out. Nor I have access to the servers or the services running our
 bot. I suggest reaching out to ilv for further assistance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10692 [Applications/GetTor]: GetTor needs official two-factor-enabled dropbox and google accounts

[Tor Bug Tracker & Wiki]

#10692: GetTor needs official two-factor-enabled dropbox and google accounts
-+--
 Reporter:  mrphs|  Owner:  (none)
 Type:  defect   | Status:  reopened
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #8542| Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mrphs):

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


Comment:

 The idea of using cloud storage services to distribute Tor via GetTor is
 so if one of them is blocked there are other ways to download it. And sure
 enough github raw service which is being used for downloading files
 directly from github is blocked in various places. Google drive and
 dropbox remain as two of the main popular platforms with higher
 collateral, especially google drive.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28089 [Core Tor/Tor]: Exhausting our bandwidth write limit stops the connection from reading

[Tor Bug Tracker & Wiki]

#28089: Exhausting our bandwidth write limit stops the connection from reading
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  regression, tor-relay, 034-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Branch: `ticket28089_034_01`
 PR: https://github.com/torproject/tor/pull/411

 FYI, so far so good on one of my test relay. No more bloating the kernel
 TCP buffers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rm):

 Could be! the only relay where I had RelayBandwidthRate limiting:

 # free
  total   used   free sharedbuffers cached
 Mem:  16327228   16101720 225508  71524  828481467484
 -/+ buffers/cache:   145513881775840
 Swap:  1048572  01048572
 # pkill -u debian-tor
 # free
  total   used   free sharedbuffers cached
 Mem:  163272284209652   12117576  71516  828561472024
 -/+ buffers/cache:2654772   13672456
 Swap:  1048572  01048572

 Three other relays with no bandwidth limit in place are not affected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27441 [Applications/Tor Browser]: Update Debian Image to use Stretch

[Tor Bug Tracker & Wiki]

#27441: Update Debian Image to use Stretch
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:12 sisbell]:
 > Removed trailing white space: https://github.com/sisbell/tor-browser-
 build/commits/android-1017

 In commit `9f90042f71ec8d509c7beb5e9efeb97a8390aa3a` from the
 `android-1017` branch, I still see a trailing white space after the
 sha256sum. Actually the commit is the same in the `android-rebased` and
 the `android-1017` branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I'm 99.9% certain the issue is caused by two things. Primarily #28089 and
 #28090 made it in part crazier.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28090 [Core Tor/Tor]: Keepalive padding cell bypasses the cell scheduler

[Tor Bug Tracker & Wiki]

#28090: Keepalive padding cell bypasses the cell scheduler
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  tor-relay, tor-scheduler, tor-kist
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When sending a keepalive cell, we look if the connection outbuf is empty
 but with the KIST scheduler, that buffer is optimized to be emptied very
 quickly.

 That cell should be able to ask the scheduler if it can queue cells in the
 outbuf. In an _ideal_ world, that cell would be handled by the scheduler
 but since it is not a circuit level "cell", we can not quickly fix that.

 The fix for padding cell is to ask the scheduler, for a specific channel,
 if it can queue in the outbuf. The KIST scheduler would do two things:
 check for pending cells and if the kernel would allow it (tcp buffer
 size).

 This made the #28089 issue more pathological.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28089 [Core Tor/Tor]: Exhausting our bandwidth write limit stops the connection from reading

[Tor Bug Tracker & Wiki]

#28089: Exhausting our bandwidth write limit stops the connection from reading
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very |  Milestone:  Tor: 0.3.5.x-final
  High   |
Component:  Core |Version:
  Tor/Tor|
 Severity:  Blocker  |   Keywords:  regression, tor-relay, 034-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In commit `488e2b00bf881b97bcc8e4bbe304845ff1d79a03`, we've refactored the
 block the connection on bandwidth logic and *one* typo got in, probably
 bad copy paste:

 {{{
 void
 connection_write_bw_exhausted(connection_t *conn, bool is_global_bw)
 {
   (void)is_global_bw;
   conn->write_blocked_on_bw = 1;
   connection_stop_reading(conn);
   reenable_blocked_connection_schedule();
 }
 }}}

 Notice the `connection_stop_reading()` call where it should be a _stop
 writing_ ... This has the really bad side effect of making tor stop
 reading on the socket if the write limit is reached, and because
 `read_blocked_on_bw` is not set to 1, it is never reenabled through our
 mainloop callback.

 This fix is *critical* else bytes accumulate in the kernel TCP buffers
 which can lead to OOM but also lost of connectivity with >= 0.3.4.x
 relays. One way to accumulate is the keepalive cell that bypasses KIST
 scheduler so tor sends it regardless if the kernel thinks it is OK. I'll
 open a ticket for this which is another problem.

 This is most likely fixing #27813.

 Appeared in 0.3.4.1-alpha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28088 [UX/Research]: User Needs Discovery: Kenya

[Tor Bug Tracker & Wiki]

#28088: User Needs Discovery: Kenya
-+--
 Reporter:  nyinz|  Owner:  nyinz
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:  antonela |Sponsor:
-+--
Changes (by antonela):

 * owner:  antonela => nyinz
 * reviewer:   => antonela
 * status:  new => assigned


Old description:

> Region: East Africa
> Country: Kenya
>
> Kenya is a developing country in EastArica which has an ethnic diversity
> that is sometimes a source of conflict. Social media is a widespread
> platform and many people use mobile devices to make social connections
> and financial transactions. The price of data is high but affordable for
> the middle to upper class citizens.
> Other challenges include high unemployment, crime and poverty.
>
> **Introduction/objective**
> We conducted the needs discovery activity in September with different
> groups of users from Mombasa and Nairobi. We did this to get a better
> comparision about how people were feeling across the country. The aim of
> the activity was;
> -to see what needs/goals people had and...
> -to guage how Tor can help fulfil them
> **
> Participants**
> We tested people aged 20-50 years from human rights backgrounds and civil
> society organisations. In total, we recieved feedback from 21 partipants
> of whom most were women. Most of the particpants had not used Tor before.
> They had knowledge about digital security and were using the internet for
> email and social media accounts. Generally, for this group the tech-level
> is medium.
>
> **Methodology**
> The trainer gave an explaination of the activity and asked them to write
> down responses to the following on post it notes:
> -who is your adversary?
> -what is the attack from your adversary?
> -How would you protect yourself from these attacks?
>
> **Results**
> (What they said)
>
> **What is happening with Tor users?**
> Most people consider the government and government agencies; cyber
> criminals; big telecoms and individuals they already know as adversaries.
> That is, factors that may deter them from doing their jobs.
>
> We saw that typically in all the groups, censorship, confiscation of
> devices and arrests are attributed to government and government agencies.
> Surveillance and tracking were also linked to the government but there
> was a sense that other adversaries were at play. For example, big
> telecoms and OR individuals.
>
> Theft of devices;targeted malware attacks like finisher/pegasus;Identify
> theft and online financial fraud were mostly attributed to Individuals.
> 'Hacker' type people or persons with malicious intent.
>
> **what are the users trying to do?**
> As mentioned, most of the participants were women. The needs discovery
> shows that women want to communicate securely and fight cyber crime. They
> want to be active on social media without the threat of gender-based
> violence.
>
> Most people had heard about encryption and want to take profit of this
> technology even though it's historically non user-friendly software. They
> want to use software that encrypts content.
>
> Most participants were concerned about the safety of their personal
> files. They want to store and share data more safely.
>
> Finally, this group is trying to browse securely and anonymously so they
> can freely work on human rights issues in the region.
>
> https://storm.torproject.org/shared/3A7z6KkZ06WlbsLSegizbppuvcXd47yVZM7NohmlGCl

New description:

 Region: East Africa
 Country: Kenya

 Kenya is a developing country in EastArica which has an ethnic diversity
 that is sometimes a source of conflict. Social media is a widespread
 platform and many people use mobile devices to make social connections and
 financial transactions. The price of data is high but affordable for the
 middle to upper class citizens. Other challenges include high
 unemployment, crime and poverty.

 **Introduction/objective**
 We conducted the needs discovery activity in September with different
 groups of users from Mombasa and Nairobi. We did this to get a better
 comparison about how people were feeling across the country. The aim of
 the activity was:
 - see what needs/goals people had
 - explore how Tor can help fulfill them
 **
 Participants**
 We tested people aged 20-50 years from human rights backgrounds and civil
 society organizations. In total, we received feedback from 21 participants
 of whom most were women. Most of the participants had not used Tor before.
 They had knowledge about digital security and were using the internet for
 email and social media accounts. Generally, for this group the tech-level
 is medium.

 **Methodology**
 The trainer gave an explanation of the 

[tor-bugs] #28088 [UX/Research]: User Needs Discovery: Kenya

[Tor Bug Tracker & Wiki]

#28088: User Needs Discovery: Kenya
-+-
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  UX/Research
  Version:   |   Severity:  Normal
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+-
 Region: East Africa
 Country: Kenya

 Kenya is a developing country in EastArica which has an ethnic diversity
 that is sometimes a source of conflict. Social media is a widespread
 platform and many people use mobile devices to make social connections and
 financial transactions. The price of data is high but affordable for the
 middle to upper class citizens.
 Other challenges include high unemployment, crime and poverty.

 **Introduction/objective**
 We conducted the needs discovery activity in September with different
 groups of users from Mombasa and Nairobi. We did this to get a better
 comparision about how people were feeling across the country. The aim of
 the activity was;
 -to see what needs/goals people had and...
 -to guage how Tor can help fulfil them
 **
 Participants**
 We tested people aged 20-50 years from human rights backgrounds and civil
 society organisations. In total, we recieved feedback from 21 partipants
 of whom most were women. Most of the particpants had not used Tor before.
 They had knowledge about digital security and were using the internet for
 email and social media accounts. Generally, for this group the tech-level
 is medium.

 **Methodology**
 The trainer gave an explaination of the activity and asked them to write
 down responses to the following on post it notes:
 -who is your adversary?
 -what is the attack from your adversary?
 -How would you protect yourself from these attacks?

 **Results**
 (What they said)

 **What is happening with Tor users?**
 Most people consider the government and government agencies; cyber
 criminals; big telecoms and individuals they already know as adversaries.
 That is, factors that may deter them from doing their jobs.

 We saw that typically in all the groups, censorship, confiscation of
 devices and arrests are attributed to government and government agencies.
 Surveillance and tracking were also linked to the government but there was
 a sense that other adversaries were at play. For example, big telecoms and
 OR individuals.

 Theft of devices;targeted malware attacks like finisher/pegasus;Identify
 theft and online financial fraud were mostly attributed to Individuals.
 'Hacker' type people or persons with malicious intent.

 **what are the users trying to do?**
 As mentioned, most of the participants were women. The needs discovery
 shows that women want to communicate securely and fight cyber crime. They
 want to be active on social media without the threat of gender-based
 violence.

 Most people had heard about encryption and want to take profit of this
 technology even though it's historically non user-friendly software. They
 want to use software that encrypts content.

 Most participants were concerned about the safety of their personal files.
 They want to store and share data more safely.

 Finally, this group is trying to browse securely and anonymously so they
 can freely work on human rights issues in the region.

 https://storm.torproject.org/shared/3A7z6KkZ06WlbsLSegizbppuvcXd47yVZM7NohmlGCl

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+--
 Reporter:  nyinz|  Owner:  nyinz
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:  antonela |Sponsor:
-+--
Description changed by antonela:

Old description:

> **Contents:**
> 1. Methodology
> 2. Results
> 3. User questions
> 4. Summary of data
> 5. Conclusions
>
> **1. Methodology**
> ''Introduction''
> The onboarding experience was designed to teach the user about Tor and
> set their expectations. The purpose of this test is to check whether
> these design objectives have been met.
> ''Sessions''
> - We spoke to 5 users using an interview style.
> - They were given a computer with the Tor Browser 8 `about:tor` open and
> asked a few questions.
> - Each session lasted about 5 minutes.
> - No dialogue was recorded, the interviewer took notes and participants
> also made comments on sticky notes.
> ''Participants''
> - These were 5 users who have used Tor before.
> - No gender was defined in these interviews
> ''Evaluation tasks/scenarios''
> We asked them the following questions:
> - What do you think about the content on this page?
> - What do you think about the Illustrations?
> - Did you find any challenges while navigating `about:tor`?
> - What would you like to see here?
> - Is there anything that does not belong on this site?
>
> **2. Results**
>
> ''Colour’s and images''
> Most users find the UI visually attractive. They feel that it is a
> friendly UI.
> Quotes:
> “The contrast is good”
> “The bold purple makes its distinguishable from other websites”
>
> ''Content''
> Most users said that the information is clear, brief but comprehensive.
> Quote:
> ‘You can have you own learning process in a slow way’
>
> ''Challenges'' (Their journey through `about:tor`)
> Most users complained about not knowing how to find the onboarding
> button.
>
> >>>The next point was an additional discovery in these interviews
> ''What would you like to see?'' (user's suggestions)
> - "Add more illustrations and screenshots in the TB manual"
> - "Make the TB manual UI similar to the TB8 onboarding UI"
> - "Maybe the onboarding launcher needs to be named"
>
> **3. User questions**
> - "Why do we have the user manual as well as the on boarding?"
> - "Circuit display: I don’t understand why it goes to an onion page."
> - "Why is the first node the guard? I did not understand the word
> ‘guard’."
>
> **4. Summary of data**
> - Most users like the visual aspects of the onboarding. The colours and
> illustrations.
> - All users commented that they found the content readable and easy to
> understand.
> - Users are having trouble finding the onboarding launcher.
> - Most users want to see similar UI changes in TB manual.
>
> **5. Conclusions**
> This test did to ask questions like ‘how does this information make you
> feel about your security?' We only collected data on visual response and
> comprehension.
> Most user’s understand the context of the onboarding. They appeared
> confident and glad that is was easy to understand.
> All users were navigating through separate corners of the site therefore
> the onboard does give direction. Many users started to customize their
> experience and pose questions.
> The onboarding helps them to engage with the browser.

New description:

 **Contents**
 1. Methodology
 2. Results
 3. User questions
 4. Summary of data
 5. Conclusions

 **1. Methodology**

 ''Introduction''
 The onboarding experience was designed to teach the user about Tor and set
 their expectations. The purpose of this test is to check whether these
 design objectives have been met.
 ''Sessions''
 - We spoke to 5 users using an interview style.
 - They were given a computer with the Tor Browser 8 `about:tor` open and
 asked a few questions.
 - Each session lasted about 5 minutes.
 - No dialogue was recorded, the interviewer took notes and participants
 also made comments on sticky notes.
 ''Participants''
 - These were 5 users who have used Tor before.
 - No gender was defined in these interviews
 ''Evaluation tasks/scenarios''
 We asked them the following questions:
 - What do you think about the content on this page?
 - What do you think about the Illustrations?
 - Did you find any challenges while navigating `about:tor`?
 - What would you like to see here?
 - Is there anything that does not belong on this site?

 **2. Results**

 ''Colour’s and images''
 Most users find the UI visually attractive. They feel that it is a
 friendly UI.
 Quotes:
 “The contrast is good”
 “The bold purple makes its distinguishable from other websites”

 ''Content''
 Most users said that the information is clear, brief but 

Re: [tor-bugs] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+--
 Reporter:  nyinz|  Owner:  nyinz
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:  antonela |Sponsor:
-+--
Changes (by antonela):

 * owner:  antonela => nyinz
 * reviewer:   => antonela
 * status:  new => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28087 [Core Tor/sbws]: Investigate circuit timeout times and if sbws is properly cleaning up circuits when it gives up on them

[Tor Bug Tracker & Wiki]

#28087: Investigate circuit timeout times and if sbws is properly cleaning up
circuits when it gives up on them
---+
 Reporter:  pastly |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 And it seems to be garbage circuits, or circuits it gave up on but didn't
 clean up.

 Here is the output of a script that shows the in-use circuits. 6
 measurements happening. **43** circuits in existence??? What the hell is
 that???

 {{{
 * 21983 tornodenumber9004 Quintex42 (185.21.216.198:443)
 * 21994 romero niftyllipika (185.21.216.198:443)
 * 21995 m CalyxInstitute09 (185.21.216.198:443)
 * 21996 AgentBolek Unnamed (185.21.216.198:443)
 * 21997 BeastieJoy61 whatconfig (185.21.216.198:443)
 * 21998 blueberryTORnode1 anonymous3 (185.21.216.198:443)
 6 streams; 6/43 circuits in use
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+--
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+--
Description changed by antonela:

Old description:

> **Contents:**
> 1. Methodology
> 2. Results
> 3. User questions
> 4. Summary of data
> 5. Conclusions
>
> **1. Methodology**
> ''Introduction''
> The onboarding experience was designed to teach the user about Tor and
> set their expectations. The purpose of this test is to check whether
> these design objectives have been met.
> ''Sessions''
> - We spoke to 5 users using an interview style.
> - They were given a computer with the Tor Browser 8 `about:tor` open and
> asked a few questions.
> - Each session lasted about 5 minutes.
> - No dialogue was recorded, the interviewer took notes and participants
> also made comments on sticky notes.
> ''Participants''
> - These were 5 users who have used Tor before.
> - No gender was defined in these interviews
> ''Evaluation tasks/scenarios''
> We asked them the following questions:
> - What do you think about the content on this page?
> - What do you think about the Illustrations?
> - Did you find any challenges while navigating `aboutL:tor`?
> - What would you like to see here?
> - Is there anything that does not belong on this site?
>
> **2. Results**
>
> ''Colour’s and images''
> Most users find the UI visually attractive. They feel that it is a
> friendly UI.
> Quotes:
> “The contrast is good”
> “The bold purple makes its distinguishable from other websites”
>
> ''Content''
> Most users said that the information is clear, brief but comprehensive.
> Quote:
> ‘You can have you own learning process in a slow way’
>
> ''Challenges'' (Their journey through `about:tor`)
> Most users complained about not knowing how to find the onboarding
> button.
>
> >>>The next point was an additional discovery in these interviews
> ''What would you like to see?'' (user's suggestions)
> - "Add more illustrations and screenshots in the TB manual"
> - "Make the TB manual UI similar to the TB8 onboarding UI"
> - "Maybe the onboarding launcher needs to be named"
>
> **3. User questions**
> - "Why do we have the user manual as well as the on boarding?"
> - "Circuit display: I don’t understand why it goes to an onion page."
> - "Why is the first node the guard? I did not understand the word
> ‘guard’."
>
> **4. Summary of data**
> - Most users like the visual aspects of the onboarding. The colours and
> illustrations.
> - All users commented that they found the content readable and easy to
> understand.
> - Users are having trouble finding the onboarding launcher.
> - Most users want to see similar UI changes in TB manual.
>
> **5. Conclusions**
> This test did to ask questions like ‘how does this information make you
> feel about your security?' We only collected data on visual response and
> comprehension.
> Most user’s understand the context of the onboarding. They appeared
> confident and glad that is was easy to understand.
> All users were navigating through separate corners of the site therefore
> the onboard does give direction. Many users started to customize their
> experience and pose questions.
> The onboarding helps them to engage with the browser.

New description:

 **Contents:**
 1. Methodology
 2. Results
 3. User questions
 4. Summary of data
 5. Conclusions

 **1. Methodology**
 ''Introduction''
 The onboarding experience was designed to teach the user about Tor and set
 their expectations. The purpose of this test is to check whether these
 design objectives have been met.
 ''Sessions''
 - We spoke to 5 users using an interview style.
 - They were given a computer with the Tor Browser 8 `about:tor` open and
 asked a few questions.
 - Each session lasted about 5 minutes.
 - No dialogue was recorded, the interviewer took notes and participants
 also made comments on sticky notes.
 ''Participants''
 - These were 5 users who have used Tor before.
 - No gender was defined in these interviews
 ''Evaluation tasks/scenarios''
 We asked them the following questions:
 - What do you think about the content on this page?
 - What do you think about the Illustrations?
 - Did you find any challenges while navigating `about:tor`?
 - What would you like to see here?
 - Is there anything that does not belong on this site?

 **2. Results**

 ''Colour’s and images''
 Most users find the UI visually attractive. They feel that it is a
 friendly UI.
 Quotes:
 “The contrast is good”
 “The bold purple makes its distinguishable from other websites”

 ''Content''
 Most users said that the information is clear, brief but 

Re: [tor-bugs] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+--
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+--
Description changed by antonela:

Old description:

> **Contents:**
> 1. Methodology
> 2. Results
> 3. User questions
> 4. Summary of data
> 5. Conclusions
>
> **1.Methodology**
> ''Introduction''
> The on boarding experience was designed to teach the user about Tor and
> set their expectations. The purpose of this test is to check whether
> these design objectives have been met.
> ''Sessions''
> - We spoke to 5 users using an interview style.
> - They were given a computer with the Tor Browser 8 `about:tor` open and
> asked a few questions.
> - Each session lasted about 5 minutes.
> - No dialogue was recorded, the interviewer took notes and participants
> also made comments on sticky notes
> ''Participants''
> - These were 5 users who have used Tor before.
> - No gender was defined in these interviews
> ''Evaluation tasks/scenarios''
> We asked them the following questions:
> - What do you think about the content on this page?
> - What do you think about the Illustrations?
> - Did you find any challenges while navigating `aboutL:tor`?
> - What would you like to see here?
> - Is there anything that does not belong on this site?
>
> **2.Results**
>
> ''Colour’s and images''
> Most users find the UI visually attractive. They feel that it is a
> friendly UI
> Quotes:
> “The contrast is good”
> “The bold purple makes its distinguishable from other websites”
>
> ''Content''
> Most users said that the information is clear, brief but comprehensive
> Quote:
> ‘You can have you own learning process in a slow way’
>
> ''Challenges'' (Their journey through `about:tor`)
> Most users complained about not knowing how to find the on-boarding
> button
>
> >>>The next point was an additional discovery in these interviews
> ''What would you like to see?'' (user's suggestions)
> - "Add more illustrations and screenshots in the TB manual"
> - "Make the TB manual UI similar to the TB8 onboarding UI"
> - "Maybe the onboarding launcher needs to be named"
>
> **3. User questions**
> - "Why do we have the user manual as well as the on boarding?"
> - "Circuit display: I don’t understand why it goes to an onion page."
> - "Why is the first node the guard? I did not understand the word
> ‘guard’."
>
> **4. Summary of data**
> - Most users like the visual aspects of the onboarding. The colours and
> illustrations.
> - All users commented that they found the content readable and easy to
> understand.
> - Users are having trouble finding the onboarding launcher.
> - Most users want to see similar UI changes in TB manual.
>
> **5.Conclusions**
> This test did to ask questions like ‘how does this information make you
> feel about your security?' We only collected data on visual response and
> comprehension.
> Most user’s understand the context of the onboarding. They appeared
> confident and glad that is was easy to understand.
> All users were navigating through separate corners of the site therefore
> the onboard does give direction. Many users started to customize their
> experience and pose questions.
> The onboarding helps them to engage with the browser.

New description:

 **Contents:**
 1. Methodology
 2. Results
 3. User questions
 4. Summary of data
 5. Conclusions

 **1. Methodology**
 ''Introduction''
 The onboarding experience was designed to teach the user about Tor and set
 their expectations. The purpose of this test is to check whether these
 design objectives have been met.
 ''Sessions''
 - We spoke to 5 users using an interview style.
 - They were given a computer with the Tor Browser 8 `about:tor` open and
 asked a few questions.
 - Each session lasted about 5 minutes.
 - No dialogue was recorded, the interviewer took notes and participants
 also made comments on sticky notes.
 ''Participants''
 - These were 5 users who have used Tor before.
 - No gender was defined in these interviews
 ''Evaluation tasks/scenarios''
 We asked them the following questions:
 - What do you think about the content on this page?
 - What do you think about the Illustrations?
 - Did you find any challenges while navigating `aboutL:tor`?
 - What would you like to see here?
 - Is there anything that does not belong on this site?

 **2. Results**

 ''Colour’s and images''
 Most users find the UI visually attractive. They feel that it is a
 friendly UI.
 Quotes:
 “The contrast is good”
 “The bold purple makes its distinguishable from other websites”

 ''Content''
 Most users said that the information is clear, brief but 

Re: [tor-bugs] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+--
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by nyinz):

 https://storm.torproject.org/shared/Pd_CdnulqCng6MunOg-
 bJr0MkslYxwH_k5zsJJtsbSI

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26976 [Applications/Tor Browser]: Hardening Wrapper Removed in Debian Stretch

[Tor Bug Tracker & Wiki]

#26976: Hardening Wrapper Removed in Debian Stretch
--+---
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:  #26693| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

 * status:  needs_information => closed
 * resolution:   => not a bug


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28086 [UX/Research]: Usability Research: Onboarding - about:tor TB8

[Tor Bug Tracker & Wiki]

#28086: Usability Research: Onboarding - about:tor TB8
-+-
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  UX/Research
  Version:   |   Severity:  Normal
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+-
 **Contents:**
 1. Methodology
 2. Results
 3. User questions
 4. Summary of data
 5. Conclusions

 **1.Methodology**
 ''Introduction''
 The on boarding experience was designed to teach the user about Tor and
 set their expectations. The purpose of this test is to check whether these
 design objectives have been met.
 ''Sessions''
 - We spoke to 5 users using an interview style.
 - They were given a computer with the Tor Browser 8 `about:tor` open and
 asked a few questions.
 - Each session lasted about 5 minutes.
 - No dialogue was recorded, the interviewer took notes and participants
 also made comments on sticky notes
 ''Participants''
 - These were 5 users who have used Tor before.
 - No gender was defined in these interviews
 ''Evaluation tasks/scenarios''
 We asked them the following questions:
 - What do you think about the content on this page?
 - What do you think about the Illustrations?
 - Did you find any challenges while navigating `aboutL:tor`?
 - What would you like to see here?
 - Is there anything that does not belong on this site?

 **2.Results**

 ''Colour’s and images''
 Most users find the UI visually attractive. They feel that it is a
 friendly UI
 Quotes:
 “The contrast is good”
 “The bold purple makes its distinguishable from other websites”

 ''Content''
 Most users said that the information is clear, brief but comprehensive
 Quote:
 ‘You can have you own learning process in a slow way’

 ''Challenges'' (Their journey through `about:tor`)
 Most users complained about not knowing how to find the on-boarding button

 >>>The next point was an additional discovery in these interviews
 ''What would you like to see?'' (user's suggestions)
 - "Add more illustrations and screenshots in the TB manual"
 - "Make the TB manual UI similar to the TB8 onboarding UI"
 - "Maybe the onboarding launcher needs to be named"

 **3. User questions**
 - "Why do we have the user manual as well as the on boarding?"
 - "Circuit display: I don’t understand why it goes to an onion page."
 - "Why is the first node the guard? I did not understand the word
 ‘guard’."

 **4. Summary of data**
 - Most users like the visual aspects of the onboarding. The colours and
 illustrations.
 - All users commented that they found the content readable and easy to
 understand.
 - Users are having trouble finding the onboarding launcher.
 - Most users want to see similar UI changes in TB manual.

 **5.Conclusions**
 This test did to ask questions like ‘how does this information make you
 feel about your security?' We only collected data on visual response and
 comprehension.
 Most user’s understand the context of the onboarding. They appeared
 confident and glad that is was easy to understand.
 All users were navigating through separate corners of the site therefore
 the onboard does give direction. Many users started to customize their
 experience and pose questions.
 The onboarding helps them to engage with the 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] #27841 [Core Tor/Tor]: Close intro circuit after introduction has been completed

[Tor Bug Tracker & Wiki]

#27841: Close intro circuit after introduction has been completed
--+--
 Reporter:  asn   |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs dos|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by neel):

 Thanks for the feedback.

 I looked at `handle_introduce_ack_success()` and found this code:
 {{{
  end:
   /* We don't need the intro circuit anymore. It did what it had to do! */
   circuit_change_purpose(TO_CIRCUIT(intro_circ),
  CIRCUIT_PURPOSE_C_INTRODUCE_ACKED);
   circuit_mark_for_close(TO_CIRCUIT(intro_circ),
 END_CIRC_REASON_FINISHED);

   /* XXX: Close pending intro circuits we might have in parallel. */
   return;
 }}}

 Isn't this already being done after the first comment above (or in
 `handle_introduce_ack_success()`)?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28061 [Core Tor/sbws]: Check prioritisation, it should make 2 measurements that are 24 appart

[Tor Bug Tracker & Wiki]

#28061: Check prioritisation, it should make 2 measurements that are 24 appart
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP nice)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28042 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by pastly):

 In case it helps.

 I've been running sbws from home for just over 24 hours.

 {{{
 (venv) matt@spacecow:~/.sbws/datadir$ sbws --log-level info stats --error-
 types
 2018-10-17 10:24:18,814 INFO MainThread sbws.py:73 - main - sbws
 0.8.1-dev0 with python 3.5.3 on Linux-4.9.0-8-amd64-x86_64-with-
 debian-9.5, stem 1.7.0, and requests 2.19.1
 7031 relays have recent results
 Mean 0.80 successful measurements per relay
 For Result: min=1 q1=1 med=2 q3=2 max=4
 For ResultSuccess: min=0 q1=0 med=1 q3=1 max=3
 For ResultErrorCircuit: min=0 q1=0 med=0 q3=1 max=4
 For ResultErrorStream: min=0 q1=0 med=0 q3=0 max=3
 12240 total results, and 45.7% are successes
 5594 success results and 6646 error results
 The fastest download was 1901.14 KiB/s
 Results come from 2018-10-16 13:58:27 to 2018-10-17 14:24:15 over a period
 of 1 day, 0:25:48
 1128/12240 (9.22%) results were error-stream
 5518/12240 (45.08%) results were error-circ
 }}}

 Months ago when I ran sbws I would see ~80% success measurement rate. The
 < 50% success rate is very concerning to me. That was probably with
 different parameters, and was definitely on a different machine than my
 home desktop. So I will now begin to run it on a server instead.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28085 [Core Tor/sbws]: Update key/values in the bandwidth file spec

[Tor Bug Tracker & Wiki]

#28085: Update key/values in the bandwidth file spec
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #27107
   Points: |   Reviewer:
  Sponsor: |
---+-
 To scale as Torflow, it was added `relay_observed_bandwidth` and
 `relay_average_bandwidth`.

 I think we should also come up with some policy to add/remove key/values.
 Even if all the ones we have so far seem useful, we are not using it.
 For instance, do we have tickets of cases where these key/values were
 needed/requested?.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

[Tor Bug Tracker & Wiki]

#27503: Disabling accessibility on Windows breaks screen readers
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by pastly):

 * cc: onionsoup (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] #27690 [Core Tor/Tor]: Update bandwidth-file-spec with scaling methods

[Tor Bug Tracker & Wiki]

#27690: Update bandwidth-file-spec with scaling methods
--+-
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-bwauth  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+-

Comment (by juga):

 Maybe we should not include any scaling method, and instead create a
 bandwidth scaling specification when we come out with an algorithm that is
 tested enough we are happy with.
 Otherwise, should we include/repeat Torflow scaling in this spec?

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

Re: [tor-bugs] #26976 [Applications/Tor Browser]: Hardening Wrapper Removed in Debian Stretch

[Tor Bug Tracker & Wiki]

#26976: Hardening Wrapper Removed in Debian Stretch
--+---
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26693| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sisbell):

 I've confirmed that we don't need binutils for android build. I'm unable
 to modify or close this ticket (perhaps I don't have permissions to do
 so?).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27441 [Applications/Tor Browser]: Update Debian Image to use Stretch

[Tor Bug Tracker & Wiki]

#27441: Update Debian Image to use Stretch
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201810   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Removed trailing white space: https://github.com/sisbell/tor-browser-
 build/commits/android-1017

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