Re: [tor-bugs] #29349 [Applications/Tor Browser]: Remove obsolete prefs from meek-http-helper-user.js

[Tor Bug Tracker & Wiki]

#29349: Remove obsolete prefs from meek-http-helper-user.js
-+--
 Reporter:  dcf  |  Owner:  tbb-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  meek, TorBrowserTeam201902R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

 * keywords:  meek => meek, TorBrowserTeam201902R
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Looks good to me, thanks! Applied to `master` (commit
 9117e69a41563c21621d7337357d9da7c8958573).

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

Re: [tor-bugs] #29348 [Applications/Tor Browser]: Add userChrome to Tor Browser to spoof scrollbars to reduce fingerprinting surface

[Tor Bug Tracker & Wiki]

#29348: Add userChrome to Tor Browser to spoof scrollbars to reduce 
fingerprinting
surface
--+--
 Reporter:  concerneduser |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  scrollbar fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 Also note that chrome affects the inner window. Showing the toolbar in
 windows makes Tor Browser (with density = compact) out by 2 pixels (loads
 as 1000x998). Using the findbar alters the inner window, as does toggling
 the menu on and off, or using the sidebar.

 Using the viewport instead means zero chrome can alter the intended size,
 which will dynamically snap into preset sizes/steps. It also minimizes the
 issues with maximizing, going full screen, and resizing 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] #29348 [Applications/Tor Browser]: Add userChrome to Tor Browser to spoof scrollbars to reduce fingerprinting surface

[Tor Bug Tracker & Wiki]

#29348: Add userChrome to Tor Browser to spoof scrollbars to reduce 
fingerprinting
surface
--+--
 Reporter:  concerneduser |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  scrollbar fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 The viewport will be standardized in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1407366 and you will not be
 able to calculate the scrollbar width. I assume - i.e. I am not entirely
 sure where the scrollbar ends up in this patch - against the edge of the
 inner window, or in the viewport

 Also note #22137 exists

 Off-topic
 > Tor reports different values for the useragent in the HTTP header
 (Windows) and the JS navigator obj (Linux). This is strange

 Not at all. It's a compromise (see #26146 if you want a LONG read)
 JS/navigator reveals 4 OSes (due to breakage), but HTTP Headers is limited
 to 2 (to reduce entropy). Sites that provide functionality based on
 OS/platform use JS naturally to detect that. But not all is lost, because
 hopefully, when https://bugzilla.mozilla.org/show_bug.cgi?id=1519122
 lands, the JS/navigator can be reduced back to 2 OSes

 > there are other fingerprinting vectors that can still give your OS away

 Indeed. The fonts differ between Tor Browser bundles. See
 https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent
 - the `[css] os` result.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29350 [Core Tor/Torsocks]: Tor SOCKS 5 proxy no longer working on version 8.0.5

[Tor Bug Tracker & Wiki]

#29350: Tor SOCKS 5 proxy no longer working on version 8.0.5
--+---
 Reporter:  zeaug1@…  |  Owner:  dgoulet
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Torsocks
  Version:|   Severity:  Major
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 connecting to Tor SOCKS 5 proxy on local port 9150 on Win7 Enterprise
 Edition 64 returns the error X'01' general SOCKS server failure.

 telnet 127.0.0.1 9150 gets a connection successfully.

 reverting back to Tor 8.0.4 brings back the functionality.

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

Re: [tor-bugs] #29349 [Applications/Tor Browser]: Remove obsolete prefs from meek-http-helper-user.js

[Tor Bug Tracker & Wiki]

#29349: Remove obsolete prefs from meek-http-helper-user.js
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => 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] #29349 [Applications/Tor Browser]: Remove obsolete prefs from meek-http-helper-user.js

[Tor Bug Tracker & Wiki]

#29349: Remove obsolete prefs from meek-http-helper-user.js
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Bug-29349-Remove-network.http.spdy.-overrides-
 from-m.patch" 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

[tor-bugs] #29349 [Applications/Tor Browser]: Remove obsolete prefs from meek-http-helper-user.js

[Tor Bug Tracker & Wiki]

#29349: Remove obsolete prefs from meek-http-helper-user.js
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  meek
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I was looking at the HTTP helper and I noticed that we no longer need to
 override the network.http.spdy.* prefs.

 I did a testbuild with this patch on top of
 50193b4aff592e79b5a45fccb2a1547cef8e2691, tried meek-azure, and got
 fingerprint [https://tlsfingerprint.io/id/bb94e801f7aee52b
 bb94e801f7aee52b] as before (as in #26241)

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

Re: [tor-bugs] #29348 [Applications/Tor Browser]: Add userChrome to Tor Browser to spoof scrollbars to reduce fingerprinting surface

[Tor Bug Tracker & Wiki]

#29348: Add userChrome to Tor Browser to spoof scrollbars to reduce 
fingerprinting
surface
--+--
 Reporter:  concerneduser |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  scrollbar fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by concerneduser):

 Sorry I cant seem to edit but I forget: I understand that there are other
 fingerprinting vectors that can still give your OS away (fonts seem like
 the most relevant one) but using the spoofed scrollbars helps users that
 want to use Tor in other ways.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29348 [Applications/Tor Browser]: Add userChrome to Tor Browser to spoof scrollbars to reduce fingerprinting surface

[Tor Bug Tracker & Wiki]

#29348: Add userChrome to Tor Browser to spoof scrollbars to reduce 
fingerprinting
surface
-+-
 Reporter:  concerneduser|  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor
 |  Browser
  Version:  Tor: unspecified |   Severity:  Normal
 Keywords:  scrollbar|  Actual Points:
  fingerprinting |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 We all know that different systems have different scrollbars. I looked it
 up right now and Tor browser reports this values for the screen object:

 width 1000
 height 900
 clientWidth 988 (yes I am on Linux)

 I found this userChrome (
 https://gist.github.com/mrkwatz/277fb19d210a7539304ca2388f24d8e3 ) and it
 makes the clientWidth become 1000 as intended (you obviously could also
 make the scrollbars the same width/height as on Windows, but I think this
 is a better approach). If something like this is included into standard
 Tor browser it would minimize segregation and thus allow users to use Tor
 on Linux/Mac while still appearing as Windows users.

 Though keep in mind that (for whatever reason) Tor reports different
 values for the useragent in the HTTP header (Windows) and the JS navigator
 obj (Linux). This is strange but irrelevant for fingerprinting if the
 scrollbar thing is not tackled since it is the same result for anyone
 else. It would get relevant though if Tor applied the custom scrollbars.

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

Re: [tor-bugs] #29347 [Obfuscation/meek]: Rewrite meek-http-helper as a WebExtension

[Tor Bug Tracker & Wiki]

#29347: Rewrite meek-http-helper as a WebExtension
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  webextension  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 The basic domain fronting option seems to be possible. You can't override
 the Host header in a [https://developer.mozilla.org/en-
 US/docs/Web/API/Fetch_API fetch] or [https://developer.mozilla.org/en-
 US/docs/Glossary/XHR_(XMLHttpRequest) XMLHttpRequest] because Host is a
 [https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
 forbidden header name]. I tried it, and any changes I made to Host were
 silently ignored. However you can set Host in
 [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/webRequest/onBeforeSendHeaders
 webRequest.onBeforeSendHeaders], at least in Firefox 65, on which I was
 testing.

 The following extension prints out the expected "I’m just a happy little
 web server." in the `--jsconsole`.

 manifest.json
 {{{
 {
 "manifest_version": 2,
 "name": "Domain fronting demo",
 "version": "1.0",

 "background": {
 "scripts": ["main.js"]
 },

 "permissions": [
 "https://*/*;,
 "webRequest",
 "webRequestBlocking"
 ]
 }
 }}}

 main.js
 {{{
 // https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/webRequest/onBeforeSendHeaders
 browser.webRequest.onBeforeSendHeaders.addListener(
 function(details) {
 let requestHeaders = details.requestHeaders.filter(
 h => h.name.toLowerCase() !== "host"
 );
 requestHeaders.push({name: "Host", value: "meek.azureedge.net"});
 return {requestHeaders: requestHeaders};
 },
 {"urls": ["*://*/*"]},
 ["blocking", "requestHeaders"]
 );

 // https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
 let resp = fetch("https://ajax.aspnetcdn.com/;)
 .then(resp => resp.text())
 .then(text => console.log(text));
 }}}

 It's a bit awkward because the listeners like `onBeforeSendHeaders` are
 global, not belonging to any single request. Ideally the extension will be
 able to handle different Host headers for different requests: we need a
 way to communicate from the outer code where we call `fetch` to the inner
 code where we modify the header. One way to do this would be to encode any
 per-request settings in a magic header or other metadata, which we strip
 and interpret in the callback. Another way would be to put a lock around
 the whole `fetch`–`onBeforeSendHeaders` so that there can only be one in
 progress at a time, and use a global variable as shared memory. I don't
 think it would hurt performance because `onBeforeSendHeaders` is called
 before anything hits the network; i.e., it should happen almost
 immediately after `fetch` and then we can release the lock.

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

Re: [tor-bugs] #29347 [Obfuscation/meek]: Rewrite meek-http-helper as a WebExtension

[Tor Bug Tracker & Wiki]

#29347: Rewrite meek-http-helper as a WebExtension
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  webextension  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by dcf:

Old description:

> Firefox 60 ESR (the current basis of Tor Browser 8) officially doesn't
> support "legacy" browser extensions using XPCOM/XUL, only the newer
> WebExtension API.
> https://www.mozilla.org/en-US/firefox/60.0esr/releasenotes/#changed
> Tor Browser still includes some legacy extensions; apparently what makes
> them keep working is a [https://gitweb.torproject.org/tor-
> browser.git/tree/browser/app/profile/000-tor-
> browser.js?id=4d0f9fa5fdd5831fbc2e28cb6c7b1056bd4deeab#n265
> extensions.legacy.exceptions] pref (#26127; thanks sukhe for knowing
> that). I don't see where meek-http-hel...@bamsoftware.com is being
> allowed, but somehow it is still working too.
>
> Assess whether it's possible to rewrite the helper as a WebExtension, and
> do it if so. Ideally it will be possible to keep 100% compatibility with
> the current helper interface; but changing meek-client and meek-client-
> torbrowser is also an option.

New description:

 Firefox 60 ESR (the current basis of Tor Browser 8) officially doesn't
 support "legacy" browser extensions using XPCOM/XUL, only the newer
 WebExtension API.
 https://www.mozilla.org/en-US/firefox/60.0esr/releasenotes/#changed
 Tor Browser still includes some legacy extensions; apparently what makes
 them keep working is a [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/000-tor-
 browser.js?id=4d0f9fa5fdd5831fbc2e28cb6c7b1056bd4deeab#n265
 extensions.legacy.exceptions] pref (#26127; thanks sukhe for knowing
 that). I don't see where !meek-http-hel...@bamsoftware.com is being
 allowed, but somehow it is still working too.

 Assess whether it's possible to rewrite the helper as a WebExtension, and
 do it if so. Ideally it will be possible to keep 100% compatibility with
 the current helper interface; but changing meek-client and meek-client-
 torbrowser is also an option.

--

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

[tor-bugs] #29347 [Obfuscation/meek]: Rewrite meek-http-helper as a WebExtension

[Tor Bug Tracker & Wiki]

#29347: Rewrite meek-http-helper as a WebExtension
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:  webextension
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Firefox 60 ESR (the current basis of Tor Browser 8) officially doesn't
 support "legacy" browser extensions using XPCOM/XUL, only the newer
 WebExtension API.
 https://www.mozilla.org/en-US/firefox/60.0esr/releasenotes/#changed
 Tor Browser still includes some legacy extensions; apparently what makes
 them keep working is a [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/000-tor-
 browser.js?id=4d0f9fa5fdd5831fbc2e28cb6c7b1056bd4deeab#n265
 extensions.legacy.exceptions] pref (#26127; thanks sukhe for knowing
 that). I don't see where meek-http-hel...@bamsoftware.com is being
 allowed, but somehow it is still working too.

 Assess whether it's possible to rewrite the helper as a WebExtension, and
 do it if so. Ideally it will be possible to keep 100% compatibility with
 the current helper interface; but changing meek-client and meek-client-
 torbrowser is also an option.

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

Re: [tor-bugs] #29346 [Metrics/Website]: Document why our CSV files are in tidy/long format and how to process them

[Tor Bug Tracker & Wiki]

#29346: Document why our CSV files are in tidy/long format and how to process 
them
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * cc: gaba (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] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
+---
 Reporter:  atagar  |  Owner:  atagar
 Type:  enhancement | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  descriptor, tor-bwauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi juga. Stem support and test coverage for bandwidth file DirPort
 downloads will need to await its implementation within tor (ticket
 #21377). Is there anything in my court here at 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] #29333 [Core Tor/Stem]: Use the bandwidth-file-spec.txt keywords as BandwidthFile attributes

[Tor Bug Tracker & Wiki]

#29333: Use the bandwidth-file-spec.txt keywords as BandwidthFile attributes
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi juga. I chose these attribute names to make usage nicer. That is to
 say...

 {{{
 print('%i / %i (%i%%) of relays are eligible' % (
   desc.eligible_count,
   desc.consensus_size,
   desc.eligible_percent,
 ))
 }}}

 ... rather than...

 {{{
 print('%i / %i (%i%%) of relays are eligible' % (
   desc.number_eligible_relays,
   desc.number_consensus_relays,
   desc.percent_eligible_relays.
 ))
 }}}

 That said, I'd be happy to defer to whatever you'd like when it comes to
 BandwidthFiles. To be clear you want the following changes...

 {{{
 * Rename desc.created_at to desc.file_created
 * Rename desc.generated_at to desc.generator_started
 * Rename desc.consensus_size to desc.number_consensus_relays
 * Rename desc.eligible_count to desc.number_eligible_relays
 * Rename desc.eligible_percent to desc.percent_eligible_relays
 * Rename desc.min_count to desc.minimum_number_eligible_relays
 * Rename desc.min_percent to desc.minimum_percent_eligible_relays
 * Rename desc.measurements to desc.bandwidth_lines
 }}}

 Is this correct?

 

 On a side note I like the spec, but felt while implementing it there's a
 few rough edges...

 * Keywords feel unnecessarily verbose to me. That's why I chose different
 names.

 * Inclusion of the **percent** attribute is redundant with other stats. I
 think it's a mistake to include derived stats since they're either
 redundant or inaccurate (what if 'eligible_count / consensus_size !=
 eligible_percent'?).

 * The **measurements** is an unstructured dictionary because bandwidth-
 file spec section 2.3 is pretty sparse. It mandates 'node_id=', 'bw=', and
 notes 'master_key_ed25519=' but otherwise defers to section 2.4.2.1 which
 depends on application version rather than bandwidth file versions.

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

Re: [tor-bugs] #29332 [Core Tor/Stem]: bandwidth_file.py test fails with TypeError in Python 3.5

[Tor Bug Tracker & Wiki]

#29332: bandwidth_file.py test fails with TypeError in Python 3.5
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Oops! I'm sorry about that juga, my bad. Fixed.

 https://gitweb.torproject.org/stem.git/commit/?id=f1c6e30d

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29346 [Metrics/Website]: Document why our CSV files are in tidy/long format and how to process them

[Tor Bug Tracker & Wiki]

#29346: Document why our CSV files are in tidy/long format and how to process 
them
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This ticket is based on a discussion in Brussels.

 The issue we talked about is that it can sometimes be difficult to import
 our per-graph CSV files into applications like LibreOffice Calc or
 services like CKAN and make charts out of them.

 The reason is that we chose to use tidy/"long" data formats for our CSV
 files. For example, the following lines are contained in the
 relayflags.csv file:

 {{{
 date,flag,relays
 2007-10-27,Exit,602
 2007-10-27,Fast,1126
 2007-10-27,Guard,244
 2007-10-27,Running,1254
 2007-10-27,Stable,586
 2007-10-28,Exit,592
 2007-10-28,Fast,1115
 2007-10-28,Guard,293
 2007-10-28,Running,1244
 2007-10-28,Stable,578
 [...]
 }}}

 However, charting applications expect the data in the messy/"wide" format:

 {{{
 date,Exit,Fast,Guard,Running,Stable
 2007-10-27,602,1126,244,1254,586
 2007-10-28,592,1115,293,1244,578
 [...]
 }}}

 We briefly discussed in Brussels to change our formats accordingly, to
 please LibreOffice Calc et al. However, after giving this some more
 thoughts, I'm opposed to this idea.

 There are reasons why we picked the tidy format in the first place: it's
 more flexible, because we don't have to worry about having to add or
 remove columns at any time. It's also somewhat easier to handle with
 statistics tools/languages like R and the very powerful tidyverse
 libraries. See also Hadley Wickham's Tidy Data paper which is a really
 good read on this topic: https://www.jstatsoft.org/article/view/v059i10

 What can we do? I don't want to make the data harder to process for
 anyone, and sometimes LibreOffice Calc or CKAN can be great tools to get a
 first impression on a data set. We can also not expect everyone to use R
 or SPSS or MATLAB. But maybe we can solve this with better documentation
 rather than changing the way we're doing things.

 The magic word here seems to be: '''pivot table'''. This random blog post
 that I just found seems to be a good start for people wanting to wrangle
 our tidy data into whatever they need for making charts:
 https://blog.datawrapper.de/pivottables/

 And this random CKAN plugin that I did ''not'' try out could be a way to
 teach CKAN how to use our tidy data formats for its preview
 visualizations: https://github.com/routetopa/ckanext-pivottable

 So, how about we document the reasons for choosing tidy data formats on
 the Statistics page and linking to a few tutorials for processing our data
 with common charting tools? Ideally, we would add links rather than write
 a lot of text on our own, though.

 Does this sound plausible?

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201902R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Looks good, thanks. Merged to `master` (commit
 50193b4aff592e79b5a45fccb2a1547cef8e2691).

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Another thing is we can probably break the `mingw-w64-clang` project a bit
 more up. I guess we could factor out the llvm/clang/lld compilation which
 would make it easier to use that part and we would not need to recompile
 it if we, say, change some `mingw-w64` commit. But I am not so sure about
 the benefits for doing the same with libcxx* etc.

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 One thing we should do in the final revision, I think, is to not symlink
 every tool we need individually (right now it is just `llvm-readobj`) but
 do something like Martin does:
 {{{
 for exec in ar ranlib nm objcopy strings strip; do
 ln -sf llvm-$exec$EXEEXT $arch-w64-mingw32-$exec$EXEEXT || true
 done
 }}}
 Rust, e.g. is complaining about a missing `x86_64-w64-mingw32-ar` and we
 probably can simplify our `mozconfig` as well that way (assuming `RANLIB`
 is just necessary because we don't symlink properly in the first place).

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ux-team, tbb-update   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---

Comment (by antonela):

 \o/

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:40 cypherpunks]:
 > Okay, finally, I have to conclude that we speak different languages. You
 usually answer something that looks relevant, but wasn't asked. Also you
 prefer to interpret my answers the way they are usually not intended to.

 That's not my intention (and neither is avoiding asnwering viable
 questions) and I am sorry if that's the impression you get.

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-rbm, TorBrowserTeam201902 => tbb-rbm,
   TorBrowserTeam201902R


Comment:

 There is a patch for review in branch `bug_29325_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_29325_v2=50193b4aff592e79b5a45fccb2a1547cef8e2691

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ux-team, tbb-update   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by gk):

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


Comment:

 Replying to [comment:20 antonela]:
 > On my side, yes.

 I parse this as "We are good with closing this ticket". :) If not, please
 reopen.

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team, tbb-update   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---

Comment (by antonela):

 On my side, yes.

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

Re: [tor-bugs] #28885 [Applications/Tor Browser]: notify users that update is downloading

[Tor Bug Tracker & Wiki]

#28885: notify users that update is downloading
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, TorBrowserTeam201902R,  |  Actual Points:
  tbb-update |
Parent ID:  #25694   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Merged to `tor-browser-60.5.0esr-8.5-1` (commit
 d176b2c555c1f0298ab8764bcb6c4fda8dc255ff).

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

Re: [tor-bugs] #25694 [Applications/Tor Browser]: Activity 3.1: Improve the user experience of updating Tor Browser

[Tor Bug Tracker & Wiki]

#25694: Activity 3.1: Improve the user experience of updating Tor Browser
--+---
 Reporter:  isabela   |  Owner:  antonela
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team, tbb-update   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor17
--+---
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 Are we good with this ticket as all child tickets are closed or is there
 work left to do 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] #29180 [Applications/Tor Browser]: MAR download stalls when about dialog is opened

[Tor Bug Tracker & Wiki]

#29180: MAR download stalls when about dialog is opened
---+--
 Reporter:  mcs|  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201902R, tbb-update  |  Actual Points:
Parent ID:  #25694 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

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


Comment:

 Looks good. I cherry-picked the patch to `tor-browser-60.5.0esr-8.5-1`
 (commit ffda294141584fdf69257e2a04fbcc7d4705ca3f).

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

Re: [tor-bugs] #28885 [Applications/Tor Browser]: notify users that update is downloading

[Tor Bug Tracker & Wiki]

#28885: notify users that update is downloading
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201902R,  |  Actual Points:
  tbb-update |
Parent ID:  #25694   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  ux-team, TorBrowserTeam201902, tbb-update => ux-team,
 TorBrowserTeam201902R, tbb-update
 * status:  needs_revision => needs_review


Comment:

 Good catch. Here is a new patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug28885-03=d176b2c555c1f0298ab8764bcb6c4fda8dc255ff

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

Re: [tor-bugs] #29328 [Applications/Tor Launcher]: account for tor 0.4.0.x's revised bootstrap status reporting

[Tor Bug Tracker & Wiki]

#29328: account for tor 0.4.0.x's revised bootstrap status reporting
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201902R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * status:  new => needs_review
 * cc: tbb-team (added)
 * keywords:   => TorBrowserTeam201902R


Comment:

 For review:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug29328-01=a40e5e1b0fec841dfb310ed6f66be778c296f9b2

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yawning):

 What does arguing over semantics contribute to fixing the build?

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 "HPKP style" was bad TOFU, deprecated, and even somewhere dead. "SPKP
 style" is not deprecated, has nothing related to HTTP and, thus, to "HPKP
 style".

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Okay, finally, I have to conclude that we speak different languages. You
 usually answer something that looks relevant, but wasn't asked. Also you
 prefer to interpret my answers the way they are usually not intended to.
 Maybe, it's a canary proof that we should continue our conversations in
 PM, or it's just your strange way to communicate. Anyway, as it's too time
 consuming to decipher your messages, and you also try to avoid answering
 viable questions, we can't make good progress that way.

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201901,   |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #29318   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:22 tom]:
 > x64 build: On first run; tor failed; noting:
 >
 > > 2/5/19, 16:46:34.346 [NOTICE] Bootstrapped 40% (loading_keys): Loading
 authority key certs
 > > 2/5/19, 16:46:34.952 [WARN] ISO time "2019-02-05 16:00:00\r" was
 unparseable
 > > 2/5/19, 16:46:34.952 [WARN] Unable to parse networkstatus consensus
 >
 > On second run (I ran firefox.exe directly but I don't think that
 mattered) it worked and I was able to load a website, youtube, play a
 video, and hit an onion site.
 >
 > x86 build: same problem with the authoritity certificates. On second run
 (this time I used the Start Tor Browser shortcut) it worked; again with a
 website, onion, and youtube. (I actually exited using IPv6 too!) I
 confirmed ASLR on the x86 build.
 >
 > All on Windows 10.

 This looks like #28614.

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201901,   |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #29318   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 x64 build: On first run; tor failed; noting:

 > 2/5/19, 16:46:34.346 [NOTICE] Bootstrapped 40% (loading_keys): Loading
 authority key certs
 > 2/5/19, 16:46:34.952 [WARN] ISO time "2019-02-05 16:00:00\r" was
 unparseable
 > 2/5/19, 16:46:34.952 [WARN] Unable to parse networkstatus consensus

 On second run (I ran firefox.exe directly but I don't think that mattered)
 it worked and I was able to load a website, youtube, play a video, and hit
 an onion site.

 x86 build: same problem with the authoritity certificates. On second run
 (this time I used the Start Tor Browser shortcut) it worked; again with a
 website, onion, and youtube. (I actually exited using IPv6 too!) I
 confirmed ASLR on the x86 build.

 All on Windows 10.

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yawning):

 "HPKP style"

 It's a pre-loaded pin list (2.7.), that searches for an intersection
 between the known pins and the cert chain(s) (2.6.), where pins are
 defined as a SPKI fingerprint using SHA256 (2.4.).

 What does arguing over semantics contribute to fixing the build?

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

Re: [tor-bugs] #29345 [- Select a component]: Can't install TOR as a service on Windows 10

[Tor Bug Tracker & Wiki]

#29345: Can't install TOR as a service on Windows 10
-+-
 Reporter:  JohnnyFrog   |  Owner:
 |  JohnnyFrog
 Type:  defect   | Status:
 |  accepted
 Priority:  Immediate|  Milestone:
Component:  - Select a component |Version:  Tor:
 |  0.3.5.7
 Severity:  Blocker  | Resolution:
 Keywords:  service unformattable error torrc|  Actual Points:
  windows 10 win |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by JohnnyFrog):

 * cc: JohnnyFrog (added)
 * severity:  Normal => Blocker


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

Re: [tor-bugs] #29345 [- Select a component]: Can't install TOR as a service on Windows 10

[Tor Bug Tracker & Wiki]

#29345: Can't install TOR as a service on Windows 10
-+-
 Reporter:  JohnnyFrog   |  Owner:
 |  JohnnyFrog
 Type:  defect   | Status:
 |  accepted
 Priority:  Immediate|  Milestone:
Component:  - Select a component |Version:  Tor:
 |  0.3.5.7
 Severity:  Normal   | Resolution:
 Keywords:  service unformattable error torrc|  Actual Points:
  windows 10 win |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by JohnnyFrog):

 * status:  new => accepted
 * owner:  (none) => JohnnyFrog


Comment:

 When installing service without specifing torrc file:
 {{{
 IMPORTANT NOTE:
 The Tor service will run under the account "NT
 AUTHORITY\LocalService".  This means
 that Tor will look for its configuration file under that
 account's Application Data directory, which is probably not
 the same as yours.
 }}}

 So the problem can be linked to NT AUTHORITY permissions on the torrc file
 or on the entire Tor folder. The actual permission groups for the folder
 and the file are: SYSTEM, Administrators, Users and Authenticated Users.
 All of these groups have complete access on the torrc file and the
 directory (I set it this way to try if it works), but however the problem
 still remains.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29345 [- Select a component]: Can't install TOR as a service on Windows 10

[Tor Bug Tracker & Wiki]

#29345: Can't install TOR as a service on Windows 10
-+-
 Reporter:  JohnnyFrog   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Component:  - Select a
 |  component
  Version:  Tor: 0.3.5.7 |   Severity:  Normal
 Keywords:  service unformattable|  Actual Points:
  error torrc windows 10 win |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 When trying to execute
 {{{
 tor.exe --service install --options -f C:\absolute\path\to\torrc
 }}}
 an  is given:

 {{{
 Running on a Post-Win2K OS, so we'll assume that the LocalService account
 exists.
 Done with CreateService.
 Service installed successfully
 Service failed to start : 
 }}}

 This bug happens when there is something written in the torrc file, but on
 other attempts it was happening when using
 {{{
 HiddenServiceAuthorizeClient basic PCNAME
 }}}
 and so deleting this line it has been starting again.

 If I leave the torrc file empty the error doesn't show up and the service
 is installed and working.

 I tried to differently formatting torrc file, so using LF and CRLF, but
 the result is the same.

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Static PK Pinning is not HPKP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29344 [Metrics/Analysis]: Consider heartbeat frequency, logging and extra-info statistics

[Tor Bug Tracker & Wiki]

#29344: Consider heartbeat frequency, logging and extra-info statistics
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The heartbeat logging, which includes statistics that we consider
 sensitive when including them in the extra-info descriptors, captures
 these statistics at smaller intervals than we do for extra-info
 descriptors. This is currently enabled by default in both the source
 distribution and the official Debian packages.

 As these are legally discoverable (by virtue of the fact that they exist)
 we should consider what attacks are enabled and what risk we place on
 guard/middle relay operators and our users by collecting them.

 The statistics have clear engineering value, but it is not clear how much
 that value degrades when looking at larger intervals.

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

Re: [tor-bugs] #29319 [Applications/Tor Browser]: Remove FTE support in Windows bundles

[Tor Bug Tracker & Wiki]

#29319: Remove FTE support in Windows bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #29307   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I think we should wait a bit to not create too much extra work.

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:38 cypherpunks]:
 > Replying to [comment:37 gk]:
 > > Replying to [comment:36 cypherpunks]:
 > > > Replying to [comment:35 gk]:
 > > > > Replying to [comment:34 cypherpunks]:
 > > > > > Replying to [comment:33 gk]:

 [snip]

 > > I you feel we are missing flags compared to what we currently have and
 what we should have, please file tickets here in case they are not filed
 yet.
 > Filed more than a year ago. Unaddressed.

 So, they are in our bug tracker? Great! We have about 1200 bugs open for
 Tor Browser and if you look carefully you'll see that the bugs get opened
 faster than we can fix them. Thus, you are very welcome to provide
 patches. We'd be happy to review them. This is after all a free software
 project and we welcome contributions.

 > > > > > > I played a bit with bumping the llvm revision to r351992 in
 order to get a proper `llvm-strip` and `llvm-objcopy` but run into a bunch
 of issues which made me pause for now (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1471698 for context).
 > > > > > Why not use 8.x branch as Mozilla?
 > > > >
 > > > > We do, but the idea was to have proper fixes for `llvm-strip` and
 `llvm-objcopy` included instead of the hacks/workarounds we and Mozilla
 have currently in place instead.
 > > > No, you don't, but LLVM seems is not going to merge those fixes into
 8.x :( There is an idea to bump LLVM to rc2 (if you wish), but build
 `llvm-strip` and `llvm-objcopy` separately from trunk.
 > >
 > > Yes, we *do* use the same revision as Mozilla on esr60: r348363.
 > It's not Mozilla official. See
 https://bugzilla.mozilla.org/show_bug.cgi?id=1512921 for the reason.

 It *is* the one Mozilla uses for mingw-w64/clang builds and thus that is
 the one we care about right now as it's what is getting tested on
 Mozilla's infra.

 > >  We could build those things separately but I am not convinced yet
 that this is worth the effort and the extra complication and potential
 instability.
 > So, building binutils now and in LLVM to create wrappers is fine for
 you, but building standalone llvm (not LLVM) to get those two utils is
 somewhat different?

 We don't build binutils, see the patch which is up for review. I am not
 strictly opposed to build those tools, as I said. It's just that it might
 be more work than it could be worth 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] #29340 [Metrics/Website]: Make the bandwidth graph more configurable

[Tor Bug Tracker & Wiki]

#29340: Make the bandwidth graph more configurable
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

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

[tor-bugs] #29343 [Metrics/Ideas]: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to Onionoo

[Tor Bug Tracker & Wiki]

#29343: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to
Onionoo
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 We put the following item on the last roadmap we made in Mexico City:

 Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to
 Onionoo.

 However, our plans have changed and we dropped it from the new roadmap we
 made in Brussels. Creating this ticket to remember the idea even though
 we're currently not working on 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

[tor-bugs] #29342 [Metrics/Ideas]: Create additional information lookup service using remote APIs and local databases

[Tor Bug Tracker & Wiki]

#29342: Create additional information lookup service using remote APIs and local
databases
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 We put the following item on the last roadmap we made in Mexico City:

 Create an additional information lookup service using remote APIs
 (RIPEstat) and local databases (MaxMind). Consider adding back the relays
 by country graph to Tor Metrics.

 However, our plans have changed and we dropped it from the new roadmap we
 made in Brussels. Creating this ticket to remember the idea even though
 we're currently not working on 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] #29328 [Applications/Tor Launcher]: account for tor 0.4.0.x's revised bootstrap status reporting

[Tor Bug Tracker & Wiki]

#29328: account for tor 0.4.0.x's revised bootstrap status reporting
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mcs):

 I filed a Core Tor ticket related to this: #29341.

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

Re: [tor-bugs] #29325 [Applications/Tor Browser]: Non-Android Tor Browser nightly builds are broken when compiling obfs4

[Tor Bug Tracker & Wiki]

#29325: Non-Android Tor Browser nightly builds are broken when compiling obfs4
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by yawning):

 Using the tag, though I'm not sure when the next time I'll feel inspired
 to add features will be.

 https://lists.torproject.org/pipermail/tor-dev/2019-February/013663.html

 https://gitlab.com/yawning/utls/tags/v0.0.9-2

 Note: My utls fork (but not upstream) depends on
 `github.com/dsnet/compress`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29341 [Core Tor/Tor]: conn_proxy reported instead of conn_pt

[Tor Bug Tracker & Wiki]

#29341: conn_proxy reported instead of conn_pt
--+---
 Reporter:  mcs   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tbb-needs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 I am using Tor 0.4.0.1-alpha (git-81f1b89efc94723f) which ships as part of
 Tor Browser 8.5a7. When I use obfs4 as my PT, `conn_proxy` and the other
 `_proxy` tags are used within bootstrap status messages instead of
 `conn_pt` and friends. Unless I misunderstand something, this is wrong.
 Sample log output:
  [notice] Bootstrapped 3% (conn_proxy): Connecting to proxy
  [notice] Bootstrapped 4% (conn_done_proxy): Connected to proxy
 The same tags are reported to the control port in the bootstrap status
 events and this same issue occurs with the meek PT and probably others.

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

Re: [tor-bugs] #29340 [Metrics/Website]: Make the bandwidth graph more configurable (was: Bring back the bandwidth graph)

[Tor Bug Tracker & Wiki]

#29340: Make the bandwidth graph more configurable
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I think we did the right thing by consolidating graphs a few weeks ago. It
 just didn't make sense to have three graphs with basically the same
 information in them. I'd rather not want to bring back the old graph just
 because people were used to it.

 What we could do though is make the one bandwidth graph we have more
 configurable. The same applies to other graphs showing related data that
 could easily be consolidated into a single, more configurable graph. Let's
 think about the bigger picture 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

[tor-bugs] #29340 [Metrics/Website]: Bring back the bandwidth graph

[Tor Bug Tracker & Wiki]

#29340: Bring back the bandwidth graph
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We consolidated this graph into the bandwidth flags graph, but some were
 using this to more cleanly represent the advertised bandwidth/consumed
 bandwidth of the network, in a way that is also legible on slides from a
 distance or on a small screen.

 We should be able to use the same CSV as the bandwidth flags and just
 write some R to make the plot differently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29339 [Core Tor]: Bind outbound ports

[Tor Bug Tracker & Wiki]

#29339: Bind outbound ports
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 It would be useful if a tor relay could be configured to use a specific
 local port range for outgoing traffic, or even bind to a single port.

 This would make tor more manageable and flexible. Especially in a
 router/fw.

 Just like with have ORPort for incoming traffic we could have OROutPort
 for outgoing ports.

 Many popular torrent applications does this.

 It would allow running tor behind a stateless firewall, which is very
 useful for low end routers with high bw Internet connections.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29338 [Core Tor/Tor]: restore HiddenServiceAuthorizeClient in v3

[Tor Bug Tracker & Wiki]

#29338: restore HiddenServiceAuthorizeClient in v3
+--
 Reporter:  Alan|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core
|  Tor/Tor
  Version:  Tor: 0.3.5.7|   Severity:  Normal
 Keywords:  tor-hs, hs-auth, client-auth, hsv3  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 According to the manual, for v3 hidden services, if the contents of
 /authorized_clients/ cannot be loaded, then the Hidden
 Service is enabled and is accessible to anyone with the onion address.
 This is a security hole.  It opens the possibility that the user intended
 for the service to require authorization, but due to files being moved or
 deleted or inaccessible or other file system problem, the hidden service
 incorrectly becomes accessible to anyone.

 Please restore the configuration option HiddenServiceAuthorizeClient for
 v3 services.  If it is set to "basic", then authentication should be
 required for the service regardless of whether
 /authorized_clients/ can be read, or alternately, if the
 authorized users cannot be read, tor should not start up or should not
 enable the hidden service.

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

Re: [tor-bugs] #29244 [Core Tor/Tor]: Travis permissions error: failed to write Cargo.lock

[Tor Bug Tracker & Wiki]

#29244: Travis permissions error: failed to write Cargo.lock
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  041-proposed, tor-ci, regression,|  Actual Points:  .2
  040-backport 035-backport 034-backport |
  033-backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.4.0.x-final => Tor: 0.3.3.x-final


Comment:

 it is merged into maint-0.3.3 and later

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

Re: [tor-bugs] #29319 [Applications/Tor Browser]: Remove FTE support in Windows bundles

[Tor Bug Tracker & Wiki]

#29319: Remove FTE support in Windows bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #29307   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:1 gk]:
 > `bug_29319` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_29319=3fc6bfc9d8df2bb558261c05c5e0c6d9bb69e942)
 has a patch for review.

 This patch looks good to me.

 >
 > Note: we should start deploying that on `master` once we'll prepare for
 the first 9.0 alpha.

 Should we create a branch for 8.5, and merge this to master? Or wait
 before merging?

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

Re: [tor-bugs] #28668 [Core Tor/Tor]: If a Tor unit test causes a BUG log, it should fail

[Tor Bug Tracker & Wiki]

#28668: If a Tor unit test causes a BUG log, it should fail
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  technical-debt, postfreeze-ok  |  Actual Points:  .1
Parent ID: | Points:
 Reviewer:  juga   |Sponsor:
---+---

Comment (by juga):

 It looks good to me, but i'm not familiar with the functions used. It'd be
 great if somebody else can review it too.
 Just left a comment about a commit 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

[tor-bugs] #29337 [Internal Services/Tor Sysadmin Team]: setup/evaluate mandos

[Tor Bug Tracker & Wiki]

#29337: setup/evaluate mandos
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-


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

Re: [tor-bugs] #29244 [Core Tor/Tor]: Travis permissions error: failed to write Cargo.lock

[Tor Bug Tracker & Wiki]

#29244: Travis permissions error: failed to write Cargo.lock
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  041-proposed, tor-ci, regression,|  Actual Points:  .2
  040-backport 035-backport 034-backport |
  033-backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:7 teor]:
 > Cargo recently started adding a comment to the start of the file:
 > https://github.com/rust-
 lang/cargo/commit/3de188f1399da693c57054ed425bc0289752edd1
 >
 > But cargo checks for frozen before writing. We are getting the write
 failed error, not the frozen error.
 > https://github.com/rust-
 
lang/cargo/blob/3de188f1399da693c57054ed425bc0289752edd1/src/cargo/ops/lockfile.rs#L105

 For posterity, the above comments are where the fix comes from.
 {{{
  armadev: the problem is that the place where tor.git is located is
 read/only, when we run distcheck it runs cargo which modifies the file by
 adding those two comments
  but because it's read-only it will fail
  but if those two lines of comment is there cargo wont touch the file
 }}}

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:37 gk]:
 > Replying to [comment:36 cypherpunks]:
 > > Replying to [comment:35 gk]:
 > > > Replying to [comment:34 cypherpunks]:
 > > > > Replying to [comment:33 gk]:
 >
 > [snip]
 Seems you're burying in it: llvm in mingw-w64-clang, mingw-w64 in
 mingw-w64-source, LLVM in llvm, mingw-w64-gcc in mingw-w64...
 [snip]
 > > > > > lld patch for optionally dealing with PE header timestamp issues
 (by zeroing them out similar to ld's -Wl,--no-insert-timestamp). I'll try
 to get that one upstreamed.
 > > > > Could you also try to get upstreamed that:
 > > > > {{{
 > > > > -  if (Args.getLastArgValue(OPT_m) != "thumb2pe" &&
 > > > > -Args.getLastArgValue(OPT_m) != "arm64pe" &&
 !Args.hasArg(OPT_dynamicbase))
 > > > > -  Add("-dynamicbase:no");
 > > > > }}}
 > > > > because it's a shame in 2019.
 > > >
 > > > We make that explicit by passing on `-Wl,--dynamicbase`, which seems
 sufficient to me without extra work and discussion.
 > > From which try? And how many other flags are missing/improperly
 passed? Silently, without discussion, yeah.
 >
 > What do you mean with "from which try"?
 Tries on Try.
 > See the patch that landed on esr60 and enabled that for mingw-w64/clang
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1520308).
 Yes, there is mentioning about that it's not an optional hardening.
 Unaddressed.
 > I you feel we are missing flags compared to what we currently have and
 what we should have, please file tickets here in case they are not filed
 yet.
 Filed more than a year ago. Unaddressed.
 > > > > > I played a bit with bumping the llvm revision to r351992 in
 order to get a proper `llvm-strip` and `llvm-objcopy` but run into a bunch
 of issues which made me pause for now (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1471698 for context).
 > > > > Why not use 8.x branch as Mozilla?
 > > >
 > > > We do, but the idea was to have proper fixes for `llvm-strip` and
 `llvm-objcopy` included instead of the hacks/workarounds we and Mozilla
 have currently in place instead.
 > > No, you don't, but LLVM seems is not going to merge those fixes into
 8.x :( There is an idea to bump LLVM to rc2 (if you wish), but build
 `llvm-strip` and `llvm-objcopy` separately from trunk.
 >
 > Yes, we *do* use the same revision as Mozilla on esr60: r348363.
 It's not Mozilla official. See
 https://bugzilla.mozilla.org/show_bug.cgi?id=1512921 for the reason.
 >  We could build those things separately but I am not convinced yet that
 this is worth the effort and the extra complication and potential
 instability.
 So, building binutils now and in LLVM to create wrappers is fine for you,
 but building standalone llvm (not LLVM) to get those two utils is somewhat
 different?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29336 [Internal Services/Tor Sysadmin Team]: split git from gitweb.tpo

[Tor Bug Tracker & Wiki]

#29336: split git from gitweb.tpo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 vineale regularly runs into OOM situations, and it's always cgit.cgi
 that's at fault.

 We might want to split off git.tpo so the gitweb thing going crazy does
 not affect proper clients.

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

Re: [tor-bugs] #29244 [Core Tor/Tor]: Travis permissions error: failed to write Cargo.lock

[Tor Bug Tracker & Wiki]

#29244: Travis permissions error: failed to write Cargo.lock
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  041-proposed, tor-ci, regression,|  Actual Points:  .2
  040-backport 035-backport 034-backport |
  033-backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 This looks like a reasonable fix for me. I did not try to build it with
 nightly locally.

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

Re: [tor-bugs] #28885 [Applications/Tor Browser]: notify users that update is downloading

[Tor Bug Tracker & Wiki]

#28885: notify users that update is downloading
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201902, tbb-  |  Actual Points:
  update |
Parent ID:  #25694   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ux-team, TorBrowserTeam201902R, tbb-update => ux-team,
 TorBrowserTeam201902, tbb-update
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:10 mcs]:
 > An updated patch is available here:
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug28885-02=2a43d0676e0b1c39e8620bf0697ca9c2d5247ded
 >
 > The bug28885-02 branch also contains a fix for #29180 since we tested
 these fixes together.

 Thanks, this looks good to me. Just a final nit (sorry for not mentioning
 that one earlier). Please avoid mixing bracing and non-bracing style
 within loops etc.:
 {{{
 +  for (let i = 0; i < elements.length; ++i) {
 +let elem = elements.item(i);
 +if (elem.hasAttribute(attrName))
 +  elem.setAttribute(attrName, label);
 +  }
 }}}
 Just braces around the if-clause and we are good to go.

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

Re: [tor-bugs] #29175 [Core Tor/Tor]: Tor 0.3.5.x mishandles empty socks5 auth

[Tor Bug Tracker & Wiki]

#29175: Tor 0.3.5.x mishandles empty socks5 auth
--+
 Reporter:  arma  |  Owner:  rl1987
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression, 035-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by jakett2):

 * cc: jakett2 (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] #29248 [Applications/Tor Browser]: Glitches in GUI after update process on win32.

[Tor Bug Tracker & Wiki]

#29248: Glitches in GUI after update process on win32.
--+---
 Reporter:  Crissy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 #28482 could be related.

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

Re: [tor-bugs] #29248 [Applications/Tor Browser]: Glitches in GUI after update process on win32.

[Tor Bug Tracker & Wiki]

#29248: Glitches in GUI after update process on win32.
--+---
 Reporter:  Crissy|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * cc: tbb-team (removed)
 * cc: mcs, brade (added)
 * keywords:   => tbb-update
 * status:  assigned => needs_information


Comment:

 Replying to [comment:2 Crissy]:
 > These glitches was not visible if hardware acceleration disabled, but
 without acceleration the performance is very bad.
 >
 > First time I have glitches after updating Tor Browser based on Firefox
 52.x to 60.x.
 > The re-installation solved this problem.
 >
 > Second - today. Also disabled acceleration helped. Looks like any
 library for hardware acceleration not changed or wrongly configured after
 update process. I enabled hardware acceleration, deleted Tor and
 TorBrowser and then installed TorBrowser. It helped. But it means: update
 process is defective.
 >
 > > How did you toggle that?
 > Please see test3.jpg file.

 Thanks, that's really helpful. Is that issue reproducible on your system
 if you use an older Tor Browser, say 8.0.4, and update it? (see:
 https://archive.torproject.org/tor-package-archive/torbrowser/8.0.4/ for
 bundles) If so, how? Do you just need to update or do you need to have
 tabs open and update? Or...?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  gk
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201901, GeorgKoppen201902|
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-

Comment (by gk):

 Thanks for the logs, that was helpful.

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

Re: [tor-bugs] #25856 [Applications/Tor Browser]: Remove XUL overlays from Torbutton

[Tor Bug Tracker & Wiki]

#25856: Remove XUL overlays from Torbutton
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:  #10760| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #10760


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

Re: [tor-bugs] #25930 [Applications/Tor Browser]: Update gcc to 7.3.0

[Tor Bug Tracker & Wiki]

#25930: Update gcc to 7.3.0
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #29335 is a duplicate.

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

Re: [tor-bugs] #25930 [Applications/Tor Browser]: Update gcc to 7.X (was: Update gcc to 7.3.0)

[Tor Bug Tracker & Wiki]

#25930: Update gcc to 7.X
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  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] #29335 [Applications/Tor Browser]: Bump GCC version we use for building Tor Browser

[Tor Bug Tracker & Wiki]

#29335: Bump GCC version we use for building Tor Browser
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * keywords:   => tbb-rbm
 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Oh, indeed I missed that one.

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

Re: [tor-bugs] #29335 [Applications/Tor Browser]: Bump GCC version we use for building Tor Browser

[Tor Bug Tracker & Wiki]

#29335: Bump GCC version we use for building Tor Browser
--+--
 Reporter:  gk|  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 cypherpunks):

 What's wrong with #25930?

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

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:21 gk]:
 > Replying to [comment:20 JeremyRand]:
 > > Updated my rbm descriptors for ARM to work with ESR 60.
 https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60 (the
 armhf-esr60 branch).  Docs still at
 https://wiki.raptorcs.com/wiki/Porting/Tor_Browser .  One noteworthy thing
 is that, due to what is probably
 https://bugzilla.mozilla.org/show_bug.cgi?id=1452128 , I needed to upgrade
 to gcc 7.3.0 / binutils 2.29.1.  I don't know if that's a dealbreaker for
 Tor (and I haven't carefully tested whether the upgrade breaks anything on
 non-ARM platforms).  Can anyone from Tor comment on whether the specific
 gcc / binutils versions used by Tor Browser were chosen for a particular
 reason, and whether upgrading them would be considered if it's the most
 straightforward way to get ARM to work?
 >
 > Thanks for working on the ARM port, really appreciated! Updating GCC to
 7.3.0 is probably no problem.

 That's now #29335 and will happen in a couple of weeks once we start with
 the 9.0 alpha series and is the last missing piece as we already bumped
 binutils to 2.31.1.

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

Re: [tor-bugs] #29326 [Core Tor/Tor]: Add units to the bandwidth key-values in the bandwidth file specification

[Tor Bug Tracker & Wiki]

#29326: Add units to the bandwidth key-values in the bandwidth file 
specification
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  postfreeze-ok, tor-bwauth, tor-spec  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * keywords:  postfreeze-ok, tor-bwauth, torspec => postfreeze-ok, tor-
 bwauth, tor-spec


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

[tor-bugs] #29335 [Applications/Tor Browser]: Bump GCC version we use for building Tor Browser

[Tor Bug Tracker & Wiki]

#29335: Bump GCC version we use for building Tor Browser
--+--
 Reporter:  gk|  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:|
--+--
 During our toolchain update we should bump the GCC version we use given
 that 6.x is not supported anymore. I think a reasonable conservative
 choice is switching to GCC 7.x.

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

Re: [tor-bugs] #28719 [Applications/Tor Browser]: Clicking on embedded links seems to cause FPI mismatch

[Tor Bug Tracker & Wiki]

#28719: Clicking on embedded links seems to cause FPI mismatch
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-8.0-issues  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 Replying to [comment:2 gk]:
 > https://blog.torproject.org/comment/279616#comment-279616 might be the
 same issue with JS resources.
 HAR (cropped bcs trac):
 {{{
   {
 "pageref": "page_1",
 "startedDateTime": "2019-02-05T10:07:36.244+00:00",
 "request": {
   "bodySize": 0,
   "method": "GET",
   "url":
 "https://hg.mozilla.org/static/3b362b7a9144/mercurial.js;,
   "httpVersion": "HTTP/2.0",
   "headers": [
 {
   "name": "Host",
   "value": "hg.mozilla.org"
 },
 {
   "name": "User-Agent",
   "value": "Mozilla/5.0 (Windows NT 6.1; rv:60.0)
 Gecko/20100101 Firefox/60.0"
 },
 {
   "name": "Accept",
   "value": "*/*"
 },
 {
   "name": "Accept-Language",
   "value": "en-US,en;q=0.5"
 },
 {
   "name": "Accept-Encoding",
   "value": "gzip, deflate, br"
 },
 {
   "name": "Referer",
   "value": "https://hg.mozilla.org/releases/mozilla-
 esr60/rev/fe547fe73bba"
 },
 {
   "name": "Connection",
   "value": "keep-alive"
 }
   ],
   "cookies": [],
   "queryString": [],
   "headersSize": 0
 },
 "response": {
   "status": 200,
   "statusText": "OK",
   "httpVersion": "HTTP/2.0",
   "headers": [
 {
   "name": "server",
   "value": "Apache"
 },
 {
   "name": "cache-control",
   "value": "max-age=31536000, immutable"
 },
 {
   "name": "content-type",
   "value": "application/javascript"
 },
 {
   "name": "strict-transport-security",
   "value": "max-age=31536000"
 },
 {
   "name": "date",
   "value": "Tue, 05 Feb 2019 10:04:36 GMT"
 },
 {
   "name": "accept-ranges",
   "value": "bytes"
 },
 {
   "name": "access-control-allow-origin",
   "value": "*"
 },
 {
   "name": "etag",
   "value": "\"3da3-572da3410ec78\""
 },
 {
   "name": "x-content-type-options",
   "value": "nosniff"
 },
 {
   "name": "last-modified",
   "value": "Tue, 07 Aug 2018 15:39:45 GMT"
 },
 {
   "name": "content-length",
   "value": "15779"
 },
 {
   "name": "X-Firefox-Spdy",
   "value": "h2"
 }
   ],
   "cookies": [],
   "content": {
 "mimeType": "application/javascript",
 "size": 0,
 "text": ""
   },
   "redirectURL": "",
   "headersSize": 0,
   "bodySize": null
 },
 "cache": {
   "afterRequest": null
 },
 "timings": {
   "blocked": 0,
   "dns": 0,
   "ssl": 0,
   "connect": 0,
   "send": 0,
   "wait": 0,
   "receive": 0
 },
 "time": 0,
 "_securityState": "secure"
   },
 }}}
 Reported zero size for cached js:
 {{{
 "mimeType": "application/javascript",
 "size": 0,
 "text": ""
 }}}

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

Re: [tor-bugs] #29139 [Internal Services/Service - trac]: False Advertising of the Tor Project

[Tor Bug Tracker & Wiki]

#29139: False Advertising of the Tor Project
--+---
 Reporter:  cypherpunks3  |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by qbi):

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


Comment:

 We sometimes have issues with vandalism via the cypherpunks account. So if
 this happens access to some or all parts will get deactivated. If the
 situation cools down, the account will be re-enabled again. That said
 currently it is possible to create tickets and it is planned to also
 enable ticket editing again.

 However the better version is to create an account for you where you
 edit/create things.

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:36 cypherpunks]:
 > Replying to [comment:35 gk]:
 > > Replying to [comment:34 cypherpunks]:
 > > > Replying to [comment:33 gk]:

 [snip]

 > > > > 4) We are omitting the `DEBUG_FLAGS` (-g -gcodeview)
 > > > But not omitting https://hg.mozilla.org/releases/mozilla-
 esr60/rev/434bde49b9c8#l3.20
 > >
 > > Yeah, I think we should make that optional, too. Mostly because we
 can't build the 32bit version as linking fails due to memory issues on my
 machines at least. And it might be better suited for setting something
 like `ac_add_options --enable-debug-symbols`.
 > Looks like a bug.

 Yes.

 > > > > lld patch for optionally dealing with PE header timestamp issues
 (by zeroing them out similar to ld's -Wl,--no-insert-timestamp). I'll try
 to get that one upstreamed.
 > > > Could you also try to get upstreamed that:
 > > > {{{
 > > > -  if (Args.getLastArgValue(OPT_m) != "thumb2pe" &&
 > > > -Args.getLastArgValue(OPT_m) != "arm64pe" &&
 !Args.hasArg(OPT_dynamicbase))
 > > > -  Add("-dynamicbase:no");
 > > > }}}
 > > > because it's a shame in 2019.
 > >
 > > We make that explicit by passing on `-Wl,--dynamicbase`, which seems
 sufficient to me without extra work and discussion.
 > From which try? And how many other flags are missing/improperly passed?
 Silently, without discussion, yeah.

 What do you mean with "from which try"? See the patch that landed on esr60
 and enabled that for mingw-w64/clang
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1520308). I you feel we are
 missing flags compared to what we currently have and what we should have,
 please file tickets here in case they are not filed yet.

 > > > > I played a bit with bumping the llvm revision to r351992 in order
 to get a proper `llvm-strip` and `llvm-objcopy` but run into a bunch of
 issues which made me pause for now (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1471698 for context).
 > > > Why not use 8.x branch as Mozilla?
 > >
 > > We do, but the idea was to have proper fixes for `llvm-strip` and
 `llvm-objcopy` included instead of the hacks/workarounds we and Mozilla
 have currently in place instead.
 > No, you don't, but LLVM seems is not going to merge those fixes into 8.x
 :( There is an idea to bump LLVM to rc2 (if you wish), but build `llvm-
 strip` and `llvm-objcopy` separately from trunk.

 Yes, we *do* use the same revision as Mozilla on esr60: r348363. We could
 build those things separately but I am not convinced yet that this is
 worth the effort and the extra complication and potential instability.

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

Re: [tor-bugs] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

#18589: Tor browser writes SiteSecurityServiceState.txt with usage history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 irc discussion clarifying what remains on this ticket:
 {{{
 > so maybe #18589 is finished, since it's only the internal chrome stuff
 that gets recorded? so long as this is a result of an active configuration
 choice made by tor browser, and not a coincidence that will get reverted
 later by accident?
  yes, that could be the case. however, there might be timestamps
 stored that give hints on when the update checks happened
  so, there are still trade-offs here
  and someone needs to track down what actually happens
  and whether that's okay in all (corner)-cases
  then we can make a decision of either fixing the bug or closing it
 as won't fix and adjust our design doc
 }}}

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

Re: [tor-bugs] #29327 [Applications/Tor Browser]: TypeError: hostName is null on about:tor page

[Tor Bug Tracker & Wiki]

#29327: TypeError: hostName is null on about:tor page
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  GeorgKoppen201902,   |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 gk]:
 > Replying to [comment:3 cypherpunks]:
 > > So, was it worth reporting or just a waste of time?
 >
 > Yes, it was worth it, thanks. However, playing games like in #28238 *is*
 a waste of time, please stop it (I am pretty sure I don't ask for the
 first time for that kind of thing).

 Oh, and this holds for blog comments, too. Thanks.

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

Re: [tor-bugs] #28359 [Core Tor/Tor]: Specify bandwidth-file-hash in torspec

[Tor Bug Tracker & Wiki]

#28359: Specify bandwidth-file-hash in torspec
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto tor-dirauth tor-bwauth|  implemented
  torspec|  Actual Points:
Parent ID:  #26698   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by juga):

 * keywords:  tor-crypto tor-dirauth => tor-crypto tor-dirauth tor-bwauth
 torspec


Comment:

 Add keywords

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29334 [Applications/Tor Browser]: Exception when running the garbage collection during new identity

[Tor Bug Tracker & Wiki]

#29334: Exception when running the garbage collection during new identity
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-torbutton, tbb-
 Severity:  Normal   |  newnym
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 During `New Identity` we run some fancy code to make sure we are really
 have a clean state after closing and reopening the browser:
 {{{
   // Run garbage collection and cycle collection after window is gone.
   // This ensures that blob URIs are forgotten.
   window.addEventListener("unload", function (event) {
 torbutton_log(3, "Initiating New Identity GC pass");
 // Clear out potential pending sInterSliceGCTimer:
 m_tb_domWindowUtils.runNextCollectorTimer();

 // Clear out potential pending sICCTimer:
 m_tb_domWindowUtils.runNextCollectorTimer();

 // Schedule a garbage collection in 4000-1000ms...
 m_tb_domWindowUtils.garbageCollect();

 // To ensure the GC runs immediately instead of 4-10s from now, we
 need
 // to poke it at least 11 times.
 // We need 5 pokes for GC, 1 poke for the interSliceGC, and 5 pokes
 for CC.
 // See nsJSContext::RunNextCollectorTimer() in
 // https://mxr.mozilla.org/mozilla-
 central/source/dom/base/nsJSEnvironment.cpp#1970.
 // XXX: We might want to make our own method for immediate full GC...
 for (let poke = 0; poke < 11; poke++) {
m_tb_domWindowUtils.runNextCollectorTimer();
 }

 // And now, since the GC probably actually ran *after* the CC last
 time,
 // run the whole thing again.
 m_tb_domWindowUtils.garbageCollect();
 for (let poke = 0; poke < 11; poke++) {
m_tb_domWindowUtils.runNextCollectorTimer();
 }
 }}}
 That leads to an exception in `chrome://extensions/content/ext-tabs-
 base.js` in some cases at
 {{{
 get frameLoader() {
 return this.browser.frameLoader;
 }}}
 as it is not guaranteed that `browser` is still a thing during that
 operation. An example where this occurs is

 1) On `about:page` open the link to our newsletter in a new tab
 2) Open the browser console
 3) Hit `New Identity`

 This got reported on our blog
 https://blog.torproject.org/comment/279507#comment-279507 ff.

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

Re: [tor-bugs] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+---
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Possibly related to #28614 (from
 https://blog.torproject.org/comment/279659#comment-279659).

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

Re: [tor-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:35 gk]:
 > Replying to [comment:34 cypherpunks]:
 > > Replying to [comment:33 gk]:
 > > > for providing mingw-w64/clang
 > > The project is mature enough to be self-hosted and decided to have a
 name 'LLVM', and `clang` is used only as a name of one of its front-ends.
 >
 > Yeah, the name `mingw-w64-clang` is good for the rbm project it shows
 that more than one part is involved and it's often contrasted with
 mignw-w64/gcc. So I think we are fine here.
 It could be good if you meant `gcc`, but not GCC, with mingw-w64/gcc.
 > > > 4) We are omitting the `DEBUG_FLAGS` (-g -gcodeview)
 > > But not omitting https://hg.mozilla.org/releases/mozilla-
 esr60/rev/434bde49b9c8#l3.20
 >
 > Yeah, I think we should make that optional, too. Mostly because we can't
 build the 32bit version as linking fails due to memory issues on my
 machines at least. And it might be better suited for setting something
 like `ac_add_options --enable-debug-symbols`.
 Looks like a bug.
 > > > lld patch for optionally dealing with PE header timestamp issues (by
 zeroing them out similar to ld's -Wl,--no-insert-timestamp). I'll try to
 get that one upstreamed.
 > > Could you also try to get upstreamed that:
 > > {{{
 > > -  if (Args.getLastArgValue(OPT_m) != "thumb2pe" &&
 > > -Args.getLastArgValue(OPT_m) != "arm64pe" &&
 !Args.hasArg(OPT_dynamicbase))
 > > -  Add("-dynamicbase:no");
 > > }}}
 > > because it's a shame in 2019.
 >
 > We make that explicit by passing on `-Wl,--dynamicbase`, which seems
 sufficient to me without extra work and discussion.
 From which try? And how many other flags are missing/improperly passed?
 Silently, without discussion, yeah.
 > > > I played a bit with bumping the llvm revision to r351992 in order to
 get a proper `llvm-strip` and `llvm-objcopy` but run into a bunch of
 issues which made me pause for now (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1471698 for context).
 > > Why not use 8.x branch as Mozilla?
 >
 > We do, but the idea was to have proper fixes for `llvm-strip` and `llvm-
 objcopy` included instead of the hacks/workarounds we and Mozilla have
 currently in place instead.
 No, you don't, but LLVM seems is not going to merge those fixes into 8.x
 :( There is an idea to bump LLVM to rc2 (if you wish), but build `llvm-
 strip` and `llvm-objcopy` separately from trunk.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29333 [Core Tor/Stem]: Use the bandwidth-file-spec.txt keywords as BandwidthFile attributes

[Tor Bug Tracker & Wiki]

#29333: Use the bandwidth-file-spec.txt keywords as BandwidthFile attributes
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  tor-bwauth
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 `BandwidthFile` descriptor was implemented in #29056.
 Some of name of the header attributes correspond to the keywords in the
 bandwidth-file-spec.txt, but not all.
 Since we might change the keywords, the implementation might be easier to
 follow the keywords using the same name for the attributes.
 Currently these attributes are:
 {{{
 consensus_size
 eligible_count
 eligible_percent
 min_count
 min_percent
 }}}

 Also, `measurements` should be named `bandwidth_lines` according to the
 specification. The bandwidth lines might not be raw measurements, but
 scaled.

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

Re: [tor-bugs] #29332 [Core Tor/Stem]: bandwidth_file.py test fails with TypeError in Python 3.5

[Tor Bug Tracker & Wiki]

#29332: bandwidth_file.py test fails with TypeError in Python 3.5
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by juga):

 I obtain similar errors when trying to obtain any of the attributes of a
 `BandwidthFile` instance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29332 [Core Tor/Stem]: bandwidth_file.py test fails with TypeError in Python 3.5

[Tor Bug Tracker & Wiki]

#29332: bandwidth_file.py test fails with TypeError in Python 3.5
---+
 Reporter:  juga   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  tor-bwauth
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When `pytest test/unit/descriptor/bandwidth_file.py` is run in a Python
 3.5 environment, it fails with the error:
 {{{
 descriptor = , entries = None

 def _parse_header(descriptor, entries):
   header = OrderedDict()
   content = io.BytesIO(descriptor.get_bytes())

   content.readline()  # skip the first line, which should be the
 timestamp

   while True:
 line = content.readline().strip()

 if not line:
   break  # end of the content
 elif line in (HEADER_DIV, HEADER_DIV_ALT):
   break  # end of header
 >   elif not header and 'node_id=' in line:
 E   TypeError: a bytes-like object is required, not 'str'

 stem/descriptor/bandwidth_file.py:116: TypeError
 }}}

 It seems something is missing with the bytes/str python 2/3 compatibility.

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

Re: [tor-bugs] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
+
 Reporter:  atagar  |  Owner:  atagar
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  descriptor, tor-bwauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by juga):

 It should include a test that do something similar to:
 {{{
 >>>
 ... import stem.descriptor
 ... import stem.descriptor.remote
 ... import stem.directory
 >>> downloader = stem.descriptor.remote.DescriptorDownloader(
 ...   document_handler = stem.descriptor.DocumentHandler.DOCUMENT,
 ... )
 >>> resource = '/tor/status-vote/next/bandwidth'
 >>> query_args = {'endpoints': [('127.10.0.1', 2003)]}
 >>> bw = downloader.query(resource, **query_args)
 >>> bw.content
 
b'1544811454\nversion=1.2.0\nearliest_bandwidth=2018-12-12T15:02:35\nfile_created=2018-12-15T08:09:48\ngenerator_started=2018-12-15T08:06:50\nlatest_bandwidth=2018-12-14T18:17:34\nminimum_number_eligible_relays=3820\nminimum_percent_eligible_relays=60\nnumber_consensus_relays=6366\nnumber_eligible_relays=0\npercent_eligible_relays=0\nsoftware=sbws\nsoftware_version=1.0.3-dev0\n='
 >>> bw.compression
 ['identity']
 >>> resource = '/tor/status-vote/next/bandwidth.z'
 >>> bw = downloader.query(resource, **query_args)
 >>> bw.content
 
b'1544811454\nversion=1.2.0\nearliest_bandwidth=2018-12-12T15:02:35\nfile_created=2018-12-15T08:09:48\ngenerator_started=2018-12-15T08:06:50\nlatest_bandwidth=2018-12-14T18:17:34\nminimum_number_eligible_relays=3820\nminimum_percent_eligible_relays=60\nnumber_consensus_relays=6366\nnumber_eligible_relays=0\npercent_eligible_relays=0\nsoftware=sbws\nsoftware_version=1.0.3-dev0\n='
 >>> bw.compression
 ['gzip']
 }}}

 As commented in comment:48:ticket:21377

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

Re: [tor-bugs] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
+
 Reporter:  atagar  |  Owner:  atagar
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  descriptor, tor-bwauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Description changed by juga:

Old description:

> Recently tor added its bandwidth authority files to the DirPort...
>
> https://gitweb.torproject.org/torspec.git/commit/?id=365d371
>
> We should add a parser and support in stem.descriptor.remote.
> > We should add a parser and support in stem.descriptor.remote. ~~This
> feature was added in tor 0.3.5 which the dirauths aren't yet running~~
> #26694 will update dir-spec.txt with the Tor version that add this
> feature once it's merged (#21377). Gonna wait to see this working in
> practice before we add stem support.

New description:

 Recently tor added its bandwidth authority files to the DirPort...

 https://gitweb.torproject.org/torspec.git/commit/?id=365d371

 We should add a parser and support in stem.descriptor.remote. ~~This
 feature was added in tor 0.3.5 which the dirauths aren't yet running~~
 #26694 will update dir-spec.txt with the Tor version that add this feature
 once it's merged (#21377). Gonna wait to see this working in practice
 before we add stem support.

--

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

Re: [tor-bugs] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
+
 Reporter:  atagar  |  Owner:  atagar
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  descriptor, tor-bwauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by juga):

 * keywords:  descriptor => descriptor, tor-bwauth


Old description:

> Recently tor added its bandwidth authority files to the DirPort...
>
> https://gitweb.torproject.org/torspec.git/commit/?id=365d371
>
> We should add a parser and support in stem.descriptor.remote. This
> feature was added in tor 0.3.5 which the dirauths aren't yet running.
> Gonna wait to see this working in practice before we add stem support.

New description:

 Recently tor added its bandwidth authority files to the DirPort...

 https://gitweb.torproject.org/torspec.git/commit/?id=365d371

 We should add a parser and support in stem.descriptor.remote.
 > We should add a parser and support in stem.descriptor.remote. ~~This
 feature was added in tor 0.3.5 which the dirauths aren't yet running~~
 #26694 will update dir-spec.txt with the Tor version that add this feature
 once it's merged (#21377). Gonna wait to see this working in practice
 before we add stem support.

--

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

Re: [tor-bugs] #26902 [Core Tor/Stem]: Download and parse bwauth files

[Tor Bug Tracker & Wiki]

#26902: Download and parse bwauth files
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  descriptor |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by juga):

 Replying to [ticket:26902 atagar]:
 > Recently tor added its bandwidth authority files to the DirPort...
 >
 > https://gitweb.torproject.org/torspec.git/commit/?id=365d371
 >
 > We should add a parser and support in stem.descriptor.remote. ~~This
 feature was added in tor 0.3.5 which the dirauths aren't yet running~~
 #26694 will update dir-spec.txt with the Tor version that add this feature
 once it's merged (#21377) . Gonna wait to see this working in practice
 before we add stem support.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29331 [Core Tor/Tor]: A bridge's new identity is not actually ignored although we say so

[Tor Bug Tracker & Wiki]

#29331: A bridge's new identity is not actually ignored although we say so
+--
 Reporter:  cypherpunks2|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.0.1-alpha  |   Severity:  Major
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I have got a bunch of these warnings recently since my bridge had a full
 reinstallation.

 {{{
 entry_guard_learned_bridge_identity(): Bug: We 'learned' an identity
 [redacted] for a bridge at [redacted], but we already knew a different one
 ([redacted]). Ignoring the new info as possibly bogus. (on Tor
 0.4.0.1-alpha 81f1b89efc94723f)
 }}}

 But it is not actually ignored: Tor bootstraps as usual, builds circuits
 using its new descriptor and writes circuit building state under its new
 identity. This could create an MiTM possibility, or maybe we need to
 elaborate a bit more on 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