[tor-bugs] #20882 [Core Tor/Tor]: Make output sort order of fallbacks configurable

[Tor Bug Tracker & Wiki]

#20882: Make output sort order of fallbacks configurable
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:  0.1   |  Parent ID:  #18828
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Implemented in #18828.

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

Re: [tor-bugs] #20871 [Core Tor/Torsocks]: Regression in Torsocks 2.2.0 breaks wget, among others

[Tor Bug Tracker & Wiki]

#20871: Regression in Torsocks 2.2.0 breaks wget, among others
---+---
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Well I found out why this is happening to my wget and not yours. I did
 more experimenting with compiling it with different flags. I've been
 compiling wget to try to eliminate variables, and realized that this
 problem occurs when wget is compiled with IPv6 disabled. IPv4 uses
 `gethostbyname()`, but if IPv6 is even enabled, then `getaddrinfo()` is
 used for both of them. See code starting on lines 327, 782, and 864 of
 wget 1.18's `src/host.c` for an example of this.

 Anyway, the debug info:

 {{{
 $ git show --pretty=oneline | head -n 1
 e54d80bc9595beeceac637b03e5c5395c07e62f7 Update version to v2.2.0

 $ git describe
 v2.2.0

 $ wget -V | head -n 3
 GNU Wget 1.18 built on linux-gnu.

 -cares +digest -gpgme +https -ipv6 -iri +large-file -metalink +nls

 $ TORSOCKS_CONF_FILE=doc/torsocks.conf TORSOCKS_LOG_LEVEL=5
 TORSOCKS_LOG_FILE_PATH=torsocks.log LD_PRELOAD=lib/torsocks/libtorsocks.so
 wget --spider https://www.torproject.org
 Spider mode enabled. Check if remote file exists.
 --2016-12-04 07:40:17--  https://www.torproject.org/
 Resolving www.torproject.org... failed: Unknown error.
 wget: unable to resolve host address ‘www.torproject.org’

 $ cat torsocks.log
 1480837264 DEBUG torsocks[36553]: Logging subsytem initialized. Level 5,
 file torsocks.log, time 1 (in init_logging() at torsocks.c:303)
 1480837264 DEBUG torsocks[36553]: Config file setting tor address to
 127.0.0.1 (in conf_file_set_tor_address() at
 config-file.c:298)
 1480837264 DEBUG torsocks[36553]: Config file setting tor port to 9050 (in
 conf_file_set_tor_port() at config-file.c:254)
 1480837264 DEBUG torsocks[36553]: [config] Onion address range set to
 127.42.42.0/24 (in set_onion_info() at config-file.c:108)
 1480837264 DEBUG torsocks[36553]: Config file doc/torsocks.conf opened and
 parsed. (in config_file_read() at config-file.c:572)
 1480837264 DEBUG torsocks[36553]: [fclose] Close caught for fd 4 (in
 tsocks_fclose() at fclose.c:45)
 1480837264 DEBUG torsocks[36553]: [onion] Pool init with subnet
 127.42.42.0 and mask 24 (in onion_pool_init() at onion.c:104)
 1480837264 DEBUG torsocks[36553]: [onion] Pool initialized with base 0,
 max_pos 255 and size 8 (in onion_pool_init() at onion.c:132)
 1480837264 DEBUG torsocks[36553]: [fclose] Close caught for fd 4 (in
 tsocks_fclose() at fclose.c:45)
 1480837264 DEBUG torsocks[36553]: [fclose] Close caught for fd 4 (in
 tsocks_fclose() at fclose.c:45)
 1480837264 DEBUG torsocks[36553]: [close] Close caught for fd 4 (in
 tsocks_close() at close.c:33)
 1480837264 DEBUG torsocks[36553]: [fclose] Close caught for fd 4 (in
 tsocks_fclose() at fclose.c:45)
 1480837264 DEBUG torsocks[36553]: [gethostbyname] Requesting
 www.torproject.org hostname (in tsocks_gethostbyname() at
 gethostbyname.c:68)
 1480837264 DEBUG torsocks[36553]: [onion] Destroying onion pool containing
 0 entry (in onion_pool_destroy() at onion.c:148)
 1480837264 DEBUG torsocks[36553]: [fclose] Close caught for fd 3 (in
 tsocks_fclose() at fclose.c:45)
 }}}

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201609, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by teor):

 I still need to fix #20539, we don't need to exclude the bad 0.2.9 alpha
 versions until the final list.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201609, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-
Changes (by teor):

 * status:  assigned => needs_information


Comment:

 My branch fallbacks-029-v2 on github https://github.com/teor2345/ has the
 changes I used to generate the lists I just attached.

 I will send out an email to tor-relays asking operators on the list to
 opt-in, wait a week or two, collate the responses, and generate the final
 list.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20883 [Core Tor/Tor]: Ignore relays without contact info when emailing potential fallback operators

[Tor Bug Tracker & Wiki]

#20883: Ignore relays without contact info when emailing potential fallback
operators
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:  fallback lorax
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 Sometimes, we want to do a mail-out to (potential) fallback operators.
 We might want to skip operators without contact details.
 Or we might want to leave them in there, so we know the how many operators
 we can't contact.

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

Re: [tor-bugs] #20885 [Core Tor/Tor]: Portions of the tor.1 man page and html doc formatted incorrectly

[Tor Bug Tracker & Wiki]

#20885: Portions of the tor.1 man page and html doc formatted incorrectly
--+--
 Reporter:  jryans|  Owner:  jryans
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * status:  assigned => needs_review


Comment:

 Patch available at https://github.com/jryans/tor/commits/doc-formatting.

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

Re: [tor-bugs] #18828 [Core Tor/Tor]: Regenerate fallback list for 0.2.9

[Tor Bug Tracker & Wiki]

#18828: Regenerate fallback list for 0.2.9
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201609, 029-accepted  |  Actual Points:
Parent ID:  #20172   | Points:  3
 Reviewer:   |Sponsor:  SponsorU-
 |  can
-+-

Comment (by teor):

 Ok, it's done.
 https://lists.torproject.org/pipermail/tor-
 relays/2016-December/03.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

[tor-bugs] #20884 [Applications/Tor Browser]: Tor Browser requires D-Bus' /etc/machine-id on Arch Linux

[Tor Bug Tracker & Wiki]

#20884: Tor Browser requires D-Bus' /etc/machine-id on Arch Linux
--+--
 Reporter:  robotanarchy  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hello Tor developers,

 I have been playing with firejail to harden the Tor Browser on Arch Linux.
 And I've noticed, that when creating a private /etc folder with only the
 minimal required files, the file /etc/machine-id is necessary or the
 Firefox in Tor Browser will segfault.

 http://0pointer.de/public/systemd-man/machine-id.html
 > The machine ID is usually generated from a random source during system
 installation and stays constant for all subsequent boots.

 This could be a potential issue, when tor browser gets exploited and
 someone can uniquely identify the host machine with that ID.

 Maybe it would be feasible to build Firefox without the D-Bus dependency
 on Linux to solve this?

 Related firejail ticket:
 https://github.com/netblue30/firejail/issues/955

 Thanks for making Tor!

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

Re: [tor-bugs] #20853 [Core Tor/Tor]: rend_config_services should use service_is_ephemeral rather than old/new->directory

[Tor Bug Tracker & Wiki]

#20853: rend_config_services should use service_is_ephemeral rather than
old/new->directory
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy refactor intro hs  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+

Comment (by jryans):

 Further updates to the patch at
 https://github.com/jryans/tor/commits/service_is_ephemeral after
 discussing on IRC:

 * Cleaned up format of the conditionals to read more clearly
 * Use `return -1` with poison checks
 * Add checks to `rend_service_poison_new_single_onion_dir` as well
   * I pulled up the log message for ephemeral services from
 `rend_service_poison_new_single_onion_dir_impl` since checking for this
 case in `rend_service_poison_new_single_onion_dir` would omit the message

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

Re: [tor-bugs] #20885 [Core Tor/Tor]: Portions of the tor.1 man page and html doc formatted incorrectly

[Tor Bug Tracker & Wiki]

#20885: Portions of the tor.1 man page and html doc formatted incorrectly
--+--
 Reporter:  jryans|  Owner:  jryans
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * owner:   => jryans
 * 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

Re: [tor-bugs] #20815 [Applications/Tor Browser]: UI dev work of security slider experience on Orfox

[Tor Bug Tracker & Wiki]

#20815: UI dev work of security slider experience on Orfox
--+--
 Reporter:  isabela   |  Owner:  synzvato
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, android   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by synzvato):

 Tor Browser Settings source code repository:
 https://git.synz.io/synzvato/tor-browser-settings/tree/master

 I was originally planning on defining an [https://developer.mozilla.org
 /en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension#Options_pages
 options page]. This is a modern way of making preference pages that have
 full API-access and that can be shown programmatically. However,
 WebExtensions [https://bugzilla.mozilla.org/show_bug.cgi?id=1268020
 doesn't yet allow] add-ons to add menu items to the Firefox for Android
 menu. That's why a mix of WebExtensions and Add-on SDK would have been
 neat.

 For now it's impossible to embed WebExtensions code into our Add-on SDK
 extension. This is due to the fact that the current stable version of
 Orfox is based on Firefox for Android `45.5.1` ESR. Support for
 [https://developer.mozilla.org/en-US/Add-
 ons/WebExtensions/Embedded_WebExtensions embedded WebExtensions] was first
 introduced in version `51`. This is worth keeping in mind, though, as
 [https://www.mozilla.org/en-US/firefox/organizations/faq/ the next ESR-
 release] will be `52`.

 That's when I started to look into `XUL`. This language was used to build
 the TorButton settings screen, but it has since been
 [https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-
 firefox-add-ons/ deprecated]. During my tests, I found that controls like
 responsive sliders didn't turn out well on mobile. I was also worried
 about the amount of effort it would take to later port this to
 WebExtensions. I decided to let go of the idea.

 Taking everything into account, the cleanest and most future-proof
 solution appears to be writing the settings page in `HTML5`, and to
 implement custom workarounds for localizations and Add-on SDK API
 interaction. The add-on injects a [https://developer.mozilla.org/en-US
 /Add-ons/SDK/Guides/Content_Scripts content script] into the settings
 page. The code emits and handles events, and alters the DOM when needed.

 The high-level [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/tabs tabs API] is not too keen on opening
 [https://developer.mozilla.org/en-
 US/docs/Mozilla/Tech/XUL/Tutorial/The_Chrome_URL Chrome URLs]. That's why
 I was [https://git.synz.io/synzvato/tor-browser-
 settings/blob/master/src/main.js#L47 forced to fall back] to some lower-
 level APIs, for bringing up the settings page when a user clicks the
 ''Orfox Settings'' menu entry.

 I have also looked into several possibilities for persisting preferences
 and concluded that the Add-on SDK's:
 * high-level [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/simple-prefs simple-prefs API] could be an option if we will
 not be altering preferences that lie outside of the scope of the add-on,
 and if we're fine with defining hidden settings within our `package.json`;
 * high-level [https://developer.mozilla.org/en-US/Add-ons/SDK/High-
 Level_APIs/simple-storage simple-storage API] is probably not a viable
 solution for storing our preferences. It seems to work sort of like DOM
 storage, but it's scoped to a specific add-on, instead of a website;
 * low-level [https://developer.mozilla.org/en-US/Add-ons/SDK/Low-
 Level_APIs/preferences_service preferences/service] is the most flexible,
 and least opinionated, alternative. It's dynamic, since it does not rely
 on pre-defined `package.json` entries, and can operate outside of the add-
 on's scope.

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

[Tor Bug Tracker & Wiki]

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > 23.92.21.42:8080 connection stalled after request
 > another_default:8080 connection stalled after request

 conn stalled after second request, first request ack'ed and some answer
 (looks like valid fte) recv'ed. second fte request ack'ed (or not) and
 nothing more recv'ed. conn stalled.

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

Re: [tor-bugs] #19420 [Metrics/Onionoo]: No AS data for some relays

[Tor Bug Tracker & Wiki]

#19420: No AS data for some relays
-+---
 Reporter:  twim |  Owner:  karsten
 Type:  defect   | Status:  reopened
 Priority:  Medium   |  Milestone:  Onionoo 3.1-1.1.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  as, asn, geoip   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Alright, I just looked at the latest database file from yesterday
 (GeoIPASNum2.zip, shasum 997932353f5824eeb760459e0ad5f8ff2226c01c), and I
 believe we should update to this one rather than keeping the May 23, 2016
 file.  Some numbers:

 ||'''Database''' || '''AS number and name'''|| '''AS number
 only'''||
 ||February 24, 2015  ||  213,789||
 318||
 ||January 4, 2016||  235,323||
 514||
 ||February 1, 2016   ||  236,474||
 544||
 ||'''May 23, 2016''' ||'''242,462'''||
 '''2,043'''||
 ||June 6, 2016   ||  187,415||
 57,773||
 ||June 13, 2016  ||  188,139||
 57,179||
 ||July 18, 2016  ||  245,367||
 1,362||
 ||October 9, 2016||  250,573||
 1,372||
 ||'''December 3, 2016''' ||'''250,447'''||
 '''1,010'''||

 I also compared AS number/names to a much older database from February 24,
 2015 that I found somewhere else on my hard disk.  My idea was that
 organization names don't change that often.  I attached a graph showing
 how newer databases compared to that old one.  It looks like if we're
 roughly back to normal again.

 [[Image(same-number-name-as-2015-02-24.png, 600px)]]

 And this new file apparently doesn't have the issues stated above with
 AS8620 or AS12876.

 So, let me ask: are there important reasons '''not''' to switch to the
 December 3, 2016 database?  If I don't hear major concerns by, Thursday,
 I'll bring this up at the next metrics team meeting and ideally decide to
 switch.

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

Re: [tor-bugs] #20501 [Core Tor/DocTor]: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?

[Tor Bug Tracker & Wiki]

#20501: Scan 0.2.9.x relays to see if they're serving an out-of-date consensus?
-+-
 Reporter:  arma |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 It's not sufficient to just scan the fallbacks, but it's certainly
 necessary.
 I'd hate to hard-code something that delivered stale consensuses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20885 [Core Tor/Tor]: Portions of the tor.1 man page and html doc formatted incorrectly

[Tor Bug Tracker & Wiki]

#20885: Portions of the tor.1 man page and html doc formatted incorrectly
--+--
 Reporter:  jryans|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Some portions of the tor.1 doc don't join paragraphs correctly, leading to
 strange output styles, especially in html view, which appears to default
 to  blocks when asciidoc is confused by the syntax.

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

Re: [tor-bugs] #20539 [Core Tor/Tor]: Make sure fallback directories aren't running buggy versions / can deliver a recent consensus

[Tor Bug Tracker & Wiki]

#20539: Make sure fallback directories aren't running buggy versions / can 
deliver
a recent consensus
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #18828| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Bug #20499 affects versions from 0.2.9.1-alpha-dev to 0.2.9.4-alpha-dev
 and version 0.3.0.0-alpha-dev, so we need to exclude these versions as
 fallbacks. We can't rely on the authorities to do this, as #20509 has not
 been deployed to directory authorities yet.

 We should also exclude authorities that can't deliver a recent microdesc
 consensus, based on the script in #20501. We already download a consensus
 from every authority to check download times. If we download a miscrodesc
 consensus, that's what clients will be downloading. And it's slightly
 faster.

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

Re: [tor-bugs] #19437 [Metrics/Onionoo]: Find more reliable and universal way to get ASN and ASorg mappings

[Tor Bug Tracker & Wiki]

#19437: Find more reliable and universal way to get ASN and ASorg mappings
-+-
 Reporter:  twim |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  asn, as, geoip, maxmind, bgp,|  Actual Points:
  organisations, diversity   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 See the update on #19420.  (I lost track where this discussion should
 happen.)

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

Re: [tor-bugs] #20853 [Core Tor/Tor]: rend_config_services should use service_is_ephemeral rather than old/new->directory

[Tor Bug Tracker & Wiki]

#20853: rend_config_services should use service_is_ephemeral rather than
old/new->directory
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy refactor intro hs  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by jryans):

 * status:  needs_revision => merge_ready


Comment:

 Okay, I wasn't sure, so was just being cautious.  I updated the patch to
 remove the extra log.

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

Re: [tor-bugs] #20886 [Core Tor/DocTor]: Track expiring approved-routers.conf entries from 2006 to 2015

[Tor Bug Tracker & Wiki]

#20886: Track expiring approved-routers.conf entries from 2006 to 2015
-+--
 Reporter:  dgoulet  |  Owner:  atagar
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch `ticket20886_01` in
 https://git.torproject.org/user/dgoulet/doctor.git

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

Re: [tor-bugs] #20886 [Core Tor/DocTor]: Track expiring approved-routers.conf entries from 2006 to 2015

[Tor Bug Tracker & Wiki]

#20886: Track expiring approved-routers.conf entries from 2006 to 2015
-+--
 Reporter:  dgoulet  |  Owner:  atagar
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 David: not that this is super critical, but, why remove old fingerprints?
 Removing old IP addresses makes a lot of sense, since they could be reused
 for totally different new people.

 But a fingerprint that was a bad relay isn't the same. Nobody is going to
 accidentally reuse that key on a new relay.

 Is it just a performance thing on the directory authorities? I don't think
 that's been critical path so far.

 Or is it a cleanliness thing for the dir auth operators? I could get
 behind that I guess. But I want us to be sure we know what we're getting
 and not getting here.

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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:  chelseakomlo
 Type:  defect| Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor:
  |  0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring, review-group-13  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet, teor |Sponsor:
--+
Changes (by chelseakomlo):

 * status:  assigned => 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

Re: [tor-bugs] #18873 [Core Tor/Tor]: Refactor circuit_predict_and_launch_new()

[Tor Bug Tracker & Wiki]

#18873: Refactor circuit_predict_and_launch_new()
--+
 Reporter:  asn   |  Owner:  chelseakomlo
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor:
  |  0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactoring, review-group-13  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet, teor |Sponsor:
--+

Comment (by chelseakomlo):

 > One final thing I was thinking about is naming. In several places in the
 code, I use the term "hs servers" , but that probably isn't right. I've
 heard the term "hidden service routers" or just "hidden services." If you
 have consistent naming for these that you prefer, let me know and I can
 fix those up as well. For example, `needs_hs_server_circuits` and
 `SUFFICIENT_UPTIME_INTERNAL_HS_SERVERS`
 >

 Ok, I chatted with asn, and hs_servers is fine, especially because it
 makes the distinction from clients in this case.

 I made fixes for Nick's feedback, final code at
 `g...@github.com:chelseakomlo/tor_patches.git`, branch `circuituse`.

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

Re: [tor-bugs] #20679 [Applications/Tor Browser]: Tor Bowser Address Spoofing.

[Tor Bug Tracker & Wiki]

#20679: Tor Bowser Address Spoofing.
--+--
 Reporter:  Dhiraj_Mishra |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dhiraj_Mishra):

 Hi ,

 Attaching reference , Mozilla is tracking the issue :

 https://bugzilla.mozilla.org/show_bug.cgi?id=1317573

 Thank you

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

Re: [tor-bugs] #19965 [Core Tor/Tor]: Log torrc option can't handle tab after severity

[Tor Bug Tracker & Wiki]

#19965: Log torrc option can't handle tab after severity
--+--
 Reporter:  arma  |  Owner:  jryans
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * status:  assigned => needs_review


Comment:

 I adjusted the parsing in `parse_log_severity_config` to accept any
 whitespace after the severity and added a basic unit test for this.

 https://github.com/jryans/tor/commits/log-severity

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

Re: [tor-bugs] #20352 [Applications/Tor Browser]: Integrate sandboxed Tor Browser into our gitian build system

[Tor Bug Tracker & Wiki]

#20352: Integrate sandboxed Tor Browser into our gitian build system
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, tbb-sandboxing,  |  Actual Points:
  GeorgKoppen201611, TorBrowserTeam201612R   |
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

 * cc: yawning (added)


Comment:

 > I'm personally leaning toward option 2a

 Did that.  The gitian env needs new libseccomp, because it will compile
 the bpf filters when you run make.  The one in backports is sufficiently
 recent, newer doesn't hurt.

 The build will fail if the library is too old.

 Sorry for the extra work, but the seccomp stuff on 32 bit intel is a lot
 better 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] #20572 [Core Tor/Tor]: hs: Remove the private key material from hs_descriptor.h

[Tor Bug Tracker & Wiki]

#20572: hs: Remove the private key material from hs_descriptor.h
+--
 Reporter:  dgoulet |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, TorCoreTeam201611  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
|  SponsorR-must
+--

Comment (by jryans):

 I'd like to make an attempt here, assuming that's okay.

 It appears the private key from `signing_kp` is used to sign the
 descriptor in `desc_encode_v3`, so if the private key is removed from
 `hs_desc_plaintext_data_t`, is there a specific place it should be moved
 so that signing can still happen?

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

Re: [tor-bugs] #20844 [Applications/Tor Browser Sandbox]: Inform me about sandbox violations

[Tor Bug Tracker & Wiki]

#20844: Inform me about sandbox violations
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 >Apparently another option is that the kernel could send the process a
 SIGSYS signal. So in that case my browser would die with a sigsys signal,
 and I could conclude that apparently a sandbox violation occurred.
 If it's allowed to catch the signal, what's to stop a hijacked Firefox
 from ignoring it? The only signals which cannot be caught are `SIGKILL`
 and `SIGSTOP`. Others can be trapped or maliciously ignored.
 > "weird issues with x86 32 bit systems forgetting whitelisted syscalls"
 Why is it permitting x86_x32 syscalls? They have questionable benefits and
 a history of vulnerabilities. Firefox does not make use of the x32 ABI
 anyway.

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

Re: [tor-bugs] #19965 [Core Tor/Tor]: Log torrc option can't handle tab after severity

[Tor Bug Tracker & Wiki]

#19965: Log torrc option can't handle tab after severity
--+--
 Reporter:  arma  |  Owner:  jryans
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * owner:   => jryans
 * 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

Re: [tor-bugs] #20846 [Metrics/Atlas]: Atlas report wrong geoip information (maybe outdated)

[Tor Bug Tracker & Wiki]

#20846: Atlas report wrong geoip information (maybe outdated)
---+-
 Reporter:  naif   |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 I'm hopeful that we can update Onionoo's database (which Atlas uses) by
 the end of the week.  See
 https://trac.torproject.org/projects/tor/ticket/19420#comment:18 for
 details.

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

Re: [tor-bugs] #20492 [Core Tor/Tor]: Tor git version is not generated in git worktrees

[Tor Bug Tracker & Wiki]

#20492: Tor git version is not generated in git worktrees
--+--
 Reporter:  teor  |  Owner:  jryans
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  log, easy |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 (To make changes in git, you will need to edit Makefile.am, then run
 ./autogen.sh .)

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

Re: [tor-bugs] #20879 [Applications/Tor Browser Sandbox]: Set rlimits in the containers.

[Tor Bug Tracker & Wiki]

#20879: Set rlimits in the containers.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 It doesn't look like Firefox is locking any memory, so `RLIMIT_MEMLOCK`
 can be safely set to 0.

 {{{
 $ pidof -s firefox
 9688

 $ prlimit -p 9688 -l
 RESOURCE DESCRIPTION SOFT  HARD UNITS
 MEMLOCK  max locked-in-memory address space 65536 65536 bytes

 $ grep -E 'Vm(Size|Lck)' /proc/9688/status
 VmSize:  1069636 kB
 VmLck: 0 kB
 }}}

 Regarding the `RLIMIT_STACK`, 8 MiB is probably overkill. It's safe, but
 very high.
 {{{
 $ prlimit -p 9688 -s
 RESOURCE DESCRIPTION   SOFTHARD UNITS
 STACKmax stack size 8388608 8388608 bytes

 $ grep -E 'Vm(Size|Stk)' /proc/9688/status
 VmSize:  1069640 kB
 VmStk:   132 kB
 }}}

 Be careful with reducing `RLIMIT_NOFILE` too low. Much lower than 512
 might be risky.
 {{{
 $ prlimit -p 9688 -n
 RESOURCE DESCRIPTION  SOFT HARD UNITS
 NOFILE   max number of open files 4096 4096

 $ ls /proc/9688/fd | sort -n | tail -n 1
 71

 $ ls /proc/9688/fd | sort -n | wc -l
 52
 }}}

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

Re: [tor-bugs] #20884 [Applications/Tor Browser]: Tor Browser requires D-Bus' /etc/machine-id on Arch Linux

[Tor Bug Tracker & Wiki]

#20884: Tor Browser requires D-Bus' /etc/machine-id on Arch Linux
--+--
 Reporter:  robotanarchy  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Oh hey, I ran into this a while ago.

 It depends on what causes firefox to assert on D-Bus not being available.
 Disabling everything that uses D-Bus all together is likely out of the
 question because it breaks things that users actually need like I-Bus.

 For what it's worth, the file just needs to be present and "well formed"
 to get past the assert, as long as you don't actually care about D-Bus.
 My sandbox monstrosity uses `000102030405060708090a0b0c0d0e0f` under the
 thought that a unique ID that's common to all sandbox users is fine, since
 it's blatantly obvious that the sandbox is present.

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

Re: [tor-bugs] #20492 [Core Tor/Tor]: Tor git version is not generated in git worktrees

[Tor Bug Tracker & Wiki]

#20492: Tor git version is not generated in git worktrees
--+--
 Reporter:  teor  |  Owner:  jryans
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  log, easy |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * owner:   => jryans
 * status:  new => assigned


Comment:

 Okay, I can reproduce after creating a worktree here.  I'll check it out.

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

Re: [tor-bugs] #20492 [Core Tor/Tor]: Tor git version is not generated in git worktrees

[Tor Bug Tracker & Wiki]

#20492: Tor git version is not generated in git worktrees
--+--
 Reporter:  teor  |  Owner:  jryans
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  log, easy |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by jryans):

 * status:  assigned => needs_review


Comment:

 As suggested in comment 5, we only need to check that .git exists.  I used
 -r to check that it's readable, which works for both a regular git repo
 and a worktree (verified both cases locally).

 https://github.com/jryans/tor/commits/git-worktree-rev

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

Re: [tor-bugs] #20492 [Core Tor/Tor]: Tor git version is not generated in git worktrees

[Tor Bug Tracker & Wiki]

#20492: Tor git version is not generated in git worktrees
--+
 Reporter:  teor  |  Owner:  jryans
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.3.9-alpha
 Severity:  Normal| Resolution:
 Keywords:  log, easy |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready
 * version:   => Tor: 0.2.3.9-alpha
 * milestone:  Tor: 0.3.??? => Tor: 0.3.0.x-final


Comment:

 Ok, works in my worktrees.

 I'd like to put this in 0.2.9, but I think it's too late, because it's at
 rc stage.
 What do you think, nickm?

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

[Tor Bug Tracker & Wiki]

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:128 cypherpunks]:
 > How to reliably confirm/deny vendor of censorship box? It can be
 fortinet, cyberoam, bluecoat, something yet.

 Here is one paper on the subject:
   http://conferences.sigcomm.org/imc/2013/papers/imc112s-dalekA.pdf
 They do an Internet-wide search (using e.g. [https://www.shodan.io/
 Shodan], [https://censys.io/ Censys], or [https://scans.io/ scans.io]
 data) for known strings. Then they submit new URLs and see whether they
 get blocked.

 Here's an example of using the technique to identify Netsweeper in
 Pakistan:
   https://citizenlab.org/2013/06/o-pakistan/

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

Re: [tor-bugs] #20844 [Applications/Tor Browser Sandbox]: Inform me about sandbox violations

[Tor Bug Tracker & Wiki]

#20844: Inform me about sandbox violations
--+-
 Reporter:  arma  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Replying to [comment:3 cypherpunks]:
 > If it's allowed to catch the signal, what's to stop a hijacked Firefox
 from ignoring it? The only signals which cannot be caught are `SIGKILL`
 and `SIGSTOP`. Others can be trapped or maliciously ignored.

 I mean, right now, proscribed calls return ENOSYS.  I was going to change
 it to trapping, and returning ENOSYS from the handler, which, firefox is
 free to ignore as it sees fit.

 > > "weird issues with x86 32 bit systems forgetting whitelisted syscalls"
 > Why is it permitting x86_x32 syscalls? They have questionable benefits
 and a history of vulnerabilities. Firefox does not make use of the x32 ABI
 anyway.

 As in, 32 bit intel, on 32 bit systems, not X32.

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

Re: [tor-bugs] #20707 [Applications/Tor Browser]: Preferences tab is broken in non-en-US 6.5a4(-hardened) builds

[Tor Bug Tracker & Wiki]

#20707: Preferences tab is broken in non-en-US 6.5a4(-hardened) builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201611R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Yes, normally all the changes on tor-browser-45.5.0esr-6.5-1 would have
 made it into 6.5a5 but dealing with a 0-day exploit is quite non-normal.
 Thus, in order to minimize the risk for breakage I decided to include only
 the most important patches into the update which left out the things you
 mentioned. 6.5a6 getting released next week will contain them.

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

Re: [tor-bugs] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Do we have a patch somewhere up for review, Arthur? I suppose it could
 take some days for the back-and-forth of the review process and 6.5a6 is
 scheduled for next week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20888 [Internal Services/Service - trac]: Ticket property changes are hidden when logged in

[Tor Bug Tracker & Wiki]

#20888: Ticket property changes are hidden when logged in
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When i am logged in as `cypherpunks` the ticket property changes are
 hidden from the ticket comments. I first noticed this on
 ticket:19965#comment:5.

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

Re: [tor-bugs] #20352 [Applications/Tor Browser]: Integrate sandboxed Tor Browser into our gitian build system

[Tor Bug Tracker & Wiki]

#20352: Integrate sandboxed Tor Browser into our gitian build system
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, tbb-sandboxing,  |  Actual Points:
  GeorgKoppen201611, TorBrowserTeam201612R   |
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:27 yawning]:
 > > I'm personally leaning toward option 2a
 >
 > Did that.  The gitian env needs new libseccomp, because it will compile
 the bpf filters when you run make.  The one in backports is sufficiently
 recent, newer doesn't hurt.
 >
 > The build will fail if the library is too old.
 >
 > Sorry for the extra work, but the seccomp stuff on 32 bit intel is a lot
 better now.

 Okay. boklm: I have bug_20352 (https://gitweb.torproject.org/user/gk
 /gitian-
 builder.git/commit/?h=bug_20352=eab8568ddcb3c4ea8b7b1d8b6321946f68b2f10e)
 in my gitian-builder repo enabling backports. It seems that might not be
 enough, though, as one has to request using backports for a package
 explicitely (IIRC). I try to test that later but my build/test machine is
 currently occupied with other high prio stuff. If you could give that a
 whirl that would be great.

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

Re: [tor-bugs] #19965 [Core Tor/Tor]: Log torrc option can't handle tab after severity

[Tor Bug Tracker & Wiki]

#19965: Log torrc option can't handle tab after severity
--+-
 Reporter:  arma  |  Owner:  jryans
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.1.10-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * keywords:   => regression
 * status:  needs_review => merge_ready
 * version:   => Tor: 0.2.1.10-alpha
 * milestone:  Tor: 0.3.??? => Tor: 0.3.0.x-final


Comment:

 Seems good to me.
 (I checked, and we don't do this anywhere else in option parsing.)

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

Re: [tor-bugs] #19965 [Core Tor/Tor]: Log torrc option can't handle tab after severity

[Tor Bug Tracker & Wiki]

#19965: Log torrc option can't handle tab after severity
--+-
 Reporter:  arma  |  Owner:  jryans
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.1.10-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 The NULL check at `test_config.c:4917` is unnecessary because `tor_free`
 can handle NULLs.

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

Re: [tor-bugs] #17516 [Applications/Tor Messenger]: GTalk connection doesn't work when "less secure apps" is turned off

[Tor Bug Tracker & Wiki]

#17516: GTalk connection doesn't work when "less secure apps" is turned off
+-
 Reporter:  am  |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Upstream, this is:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1238631
 https://bugzilla.mozilla.org/show_bug.cgi?id=1258255

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

Re: [tor-bugs] #15015 [Core Tor/Tor]: tor --verify-config should not bind to ports

[Tor Bug Tracker & Wiki]

#15015: tor --verify-config should not bind to ports
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, 027-triaged-1-out, intro  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by jryans):

 Should a new option (such as `--parse-config`) be added for the more
 minimal step of parsing only and `--verify-config` left as is to preserve
 compatibility?  Or is it okay to change the behavior of `--verify-config`
 directly?

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

Re: [tor-bugs] #20853 [Core Tor/Tor]: rend_config_services should use service_is_ephemeral rather than old/new->directory

[Tor Bug Tracker & Wiki]

#20853: rend_config_services should use service_is_ephemeral rather than
old/new->directory
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy refactor intro hs  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Looks good, but we don't really need the extra `log_info(LD_REND,
 "Ephemeral HS started in non-anonymous mode.");`, because the BUG() macro
 logs a message anyway.

 But it's harmless, so it's up to you whether you want to revise it.
 Otherwise, please flip it to "ready to merge".

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

Re: [tor-bugs] #20352 [Applications/Tor Browser]: Integrate sandboxed Tor Browser into our gitian build system

[Tor Bug Tracker & Wiki]

#20352: Integrate sandboxed Tor Browser into our gitian build system
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, tbb-sandboxing,  |  Actual Points:
  GeorgKoppen201611, TorBrowserTeam201612R   |
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 So, I just pushed a huge change to go back to libseccomp2 for all my
 seccomp needs, primarily so I can filter arguments on x86.  This
 *shouldn't* change anything since we pull it down as a dependency anyway,
 but if anything breaks there, that would be why.

 Debian jessie users will need to fetch libseccomp2 from backports to run
 the thing in addition to bubblewrap, because the library flat out refuses
 to filter by conditional on anything pre 2.2.1, but, filtering arguments
 is kind of important.

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

Re: [tor-bugs] #20352 [Applications/Tor Browser]: Integrate sandboxed Tor Browser into our gitian build system

[Tor Bug Tracker & Wiki]

#20352: Integrate sandboxed Tor Browser into our gitian build system
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, tbb-sandboxing,  |  Actual Points:
  GeorgKoppen201611, TorBrowserTeam201612R   |
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Ugh. Old libseccomp doesn't let me distinguish the version of the shared
 library at runtime (the version was a bunch of #defines).  So the build's
 broken right now, because libseccomp packages from backports are needed to
 get something that will function at all, and even then the packages *may*
 misbehave on jessie (amd64) systems.

 This is the upstream issue that's fixed in newer releases:
 
https://github.com/seccomp/libseccomp/commit/b43a7dde03f96ce6a291eb58f620c5d2b7700b51

 I'm not sure what the best solution here is out of:

  1. Kludge out the version check and pray that we don't hit the edge case.
  2. Ship pre-generated bpf.
a. Generated at compile time (adds another step to the build process,
 the gitian descriptor needs to be modified to pull in backports packages,
 but the user does not need ibseccomp at all).
b. Generated by me, embedded in the tree as static assets.  The build
 system won't need libesccomp at all, and neither will the user.
  3. Drop 32 bit intel support and go back to using gosecco.

 I'm personally leaning toward option 2a, with a plan to fall back to 2b,
 since the work involved is comparable.

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

Re: [tor-bugs] #20205 [Applications/Tor Messenger]: Implement SASL EXTERNAL

[Tor Bug Tracker & Wiki]

#20205: Implement SASL EXTERNAL
+-
 Reporter:  arlolra |  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Replying to [comment:1 dcf]:
 > I was just looking for this feature :)

 SASL ECDSA-NIST256P-CHALLENGE went out in TM v0.3.0b1 as a quasi-
 undocumented feature.

 Here're some notes on how to use it,
 https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/SASL

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20886 [Core Tor/DocTor]: Track expiring approved-routers.conf entries from 2006 to 2015

[Tor Bug Tracker & Wiki]

#20886: Track expiring approved-routers.conf entries from 2006 to 2015
-+
 Reporter:  dgoulet  |  Owner:  atagar
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/DocTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 We are about to remove the 4273 entries of the approved-routers.conf from
 the dirauth-conf git repository. Those entries are all fingerprints dating
 back from 2006 to end of 2015.

 This commit is to track those with the tracked_relays.cfg module of
 DocTor.

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

Re: [tor-bugs] #15015 [Core Tor/Tor]: tor --verify-config should not bind to ports

[Tor Bug Tracker & Wiki]

#15015: tor --verify-config should not bind to ports
-+-
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, 027-triaged-1-out, intro  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Hmm, there are two different use cases here:
 1) I am not running a relay, and I'm about to start one, and I want to
 know if it will work,
 2) I am running a relay, and I'm about to change the config, and I want to
 know if it will work

 We can bind to ports in case 1), but not case 2).

 I think we should add a new option `--parse-config` that just does an
 options_verify().
 Of course, the risk is that it will succeed, and then when it gets to
 options_act(), it will fail because it suddenly finds out it can't do what
 it wanted to do.

 But for `--verify-config`, the risk is that it will fail unnecessarily,
 because it could do the things if only it were the existing tor process.

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

Re: [tor-bugs] #20684 [Core Tor/Tor]: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM

[Tor Bug Tracker & Wiki]

#20684: DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy intro typo  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Bug #20887 is another bug in this code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20887 [Core Tor/Tor]: DIRCACHE_MIN_MB_BANDWIDTH does not stringify on FreeBSD, we should use %d instead

[Tor Bug Tracker & Wiki]

#20887: DIRCACHE_MIN_MB_BANDWIDTH does not stringify on FreeBSD, we should use 
%d
instead
--+-
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  easy intro refactor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 A FreeBSD relay operator reports the message:
 {{{
 [WARN] Being a directory cache (default) with less than
 DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume
 most of the available resources, consider disabling this functionality by
 setting the DirCache option to 0
 }}}

 So we should print the macro value the same way we do every other value,
 using "%d" in the string, and passing it as an argument.

 This macro will change name in #20684.

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

Re: [tor-bugs] #18539 [Applications/Tor Messenger]: Add Exception is finicky

[Tor Bug Tracker & Wiki]

#18539: Add Exception is finicky
+
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Testing storing exceptions again, and on Windows, I've had no issues.

 Also, since OFTC is now using Let's Encrypt, the experience should be much
 improved.

 > There's a workaround (sorta) described here

 Some of the initial confusion around the exception not storing was
 probably that they had a different cert. for each server, and you'd be
 directed to a different one at each connection attempt.

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