Re: [tor-bugs] #25226 [Core Tor/Tor]: Circuit cell queue can fill up memory

[Tor Bug Tracker & Wiki]

#25226: Circuit cell queue can fill up memory
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-cell, tor-relay, tor-dos,|  Actual Points:
  033-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > We can change **this part** of the spec.

 ¯\_(ツ)_/¯

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, boklm201802 => tbb-rbm, boklm201802,
 TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 There is a patch for review in branch `bug_16472_v5`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v5&id=f338e127e856d3db876ebe46e62799f0fb63fb78

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

Re: [tor-bugs] #25304 [Applications/Tor Browser]: Update gcc to 6.4.0

[Tor Bug Tracker & Wiki]

#25304: Update gcc to 6.4.0
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802,   |  Actual Points:
  boklm201802|
Parent ID:  #24631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * parent:   => #24631


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB - radio.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB - select.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB - select - active.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by antonela):

 Thanks @mcs for the explainer.
 So, in that case, my recommendation is to use a select

 
https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB%20-%20select.png
 
https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB%20-%20select%20-%20active.png

 I made mockups for both versions so we can see how it looks/ feels without
 development effort.

 
https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB%20-%20radio.png

 I'd like to suggest showing a limited qty of previous connections. Also,
 since the main action here was Request a New Bridge, I'd recommend to have
 it in the first place.

 We should check the impact of this iteration on all user flows, eg.
 Connection Error with obfs4 and back to request a new bridge.

 About the captcha, will it show after the user selects which kind of
 bridge he wants?

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB - radio.2.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB - radio.png" 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] #25381 [Core Tor/Tor]: Add crypto_rand_double_sign() in C and Rust

[Tor Bug Tracker & Wiki]

#25381: Add crypto_rand_double_sign() in C and Rust
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  2
 Reviewer:|Sponsor:  SponsorQ
--+
Changes (by teor):

 * status:  assigned => needs_revision


Comment:

 I was using an old version of rustc, the new version handles the doctests
 correctly, and they fail.
 So I have some bugs to fix,

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by gk):

 That is an impressive work mcs and brade, especially given all the delays
 during this project and the workarounds you needed to find for those as
 well. Big Thanks!

 Here comes the first part of my review. It's mostly nits so far (5) has a
 question, though):

 1)

 oncommand="onBridgeTypeRadioChange()" is not properly aligned:

 {{{
 -   label="&torsettings.useBridges.default;"
 selected="true"/>
 +   label="&torsettings.useBridges.default;"
 selected="true"
 +oncommand="onBridgeTypeRadioChange()"/>
 }}}

 2)

 Copyright -> "2018" in network-settings-wizard.xul

 3)

 Copyright -> "2018" in network-settings.xul

 4) `let proxySettings;` as we are using it later on
 even if no proxy settings got specified should we initialize it somehow,
 say to `undefined`?

 5)

 if (!isUsingBridgeDBBridges)
 {
   gBridgeDBBridges = undefined;
   showBridgeDBBridges();
 }

 Why do we have the `showBridgeDBBridges()` call here if we are not using
 BridgeDB bridges (i.e. there
 aren't any to begin with)?

 6)

 Please, no mix of braces/non-braces style in if-else-clauses:
 {{{
 +  if (aErr.message)
 +details = aErr.message;
 +  else if (aErr.code)
 +  {
 +if (aErr.code < 1000)
 +  details = aErr.code; // HTTP status code
 +else
 +  details = "0x" + aErr.code.toString(16); // nsresult
 +  }
 }}}
 {{{
 if (this._processStdoutLines())
   aResolve();
 else
 {
   // The PT handshake has not finished yet. Read more data.
   this._startStdoutRead(aResolve, aReject);
 }
 }}}

 7)

 It might not matter much but is socks4 really the thing we should test
 first
 (meaning the protocol we expect to get used in the majority of cases) when
 creating the proxy URL?

 8)

 "//  waitForCaptchaResponse" -> "// waitForCaptchaResponse" (and
 whitespace too much after the slashes)

 9)

 Do we need a spec update or an updated link to the spec you gave in `tl-
 bridgedb.jsm`? 'type': 'moat client supported transports' got changed
 'type':'client-transports' etc.
 So, https://github.com/isislovecruft/bridgedb/tree/fix/22871#requesting-
 bridges does
 not have latest version it seems?

 10)

 "Error Object" -> "Error object" and "a a text" in
 {{{
 // Extended Error Object which is used when we have a numeric code and a
 // a text error message.
 }}}

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

Re: [tor-bugs] #24707 [Metrics]: Define R coding guidelines for Metrics' products

[Tor Bug Tracker & Wiki]

#24707: Define R coding guidelines for Metrics' products
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 From a recent
 [https://trac.torproject.org/projects/tor/ticket/25259#comment:1 R tuning]
 ticket and [https://gitweb.torproject.org/metrics-
 web.git/commit/?id=ab7d546a9dae35efdfc2c1f8c4a09e473df72747 commit]:
   Performing pre-processing separately, helping R by defining read types,
 and avoid multiple casting operations.

 So, always use `colClasses` parameter in `read.csv` and watch out for
 implicit casts.

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

Re: [tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, performance, |  Actual Points:
  review-group-32, 033-must  |
Parent ID:   | Points:
 Reviewer:  asn, teor|Sponsor:
-+-

Comment (by dgoulet):

 Two fixup commits pushed to address teor's review above. First one to fix
 the hashing and the second for the compilation issue.

 Same OnionGit
 Branch: `bug24767_033_02`

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by gk):

 Here comes another round:

 11) "We allow response.data to be an array or object". What about
 `response.errors`?

 12) Spec says 'error', yet we check for `response.errors`, typo?

 13) braces mix

   if (!response.data)
   {
   ...
   }
   else if

 14)  // Returns a promise that is fulfilled with an object that contains:
  // captchaImage

 Do you mean "image" here instead of "captchaImage"? I looked at the spec
 and thought this was another instance of the spec you linked to being
 outdated but then I saw `image` in `_parseFetchResponse()`. If so, could
 you order the attributes in the comment lines: `transport`, `image`, and
 `challenge` as outlined in the spec?

 15)

 {{{
  * If there is no overlap between the type of bridge we requested and
  * the transports which BridgeDB supports, the response is the same
 except
  * the transport property will contain an array of supported
 transports:
  * ...
  * "transport": [ "TRANSPORT", "TRANSPORT", ... ],
 }}}

 Really? The spec seems to say

 {{{
 {
   'data': {
 'version': '0.1.0',
 'type': 'moat server supported transports',
 'supported': [ 'TRANSPORT', 'TRANSPORT', ... ],
   }
 }
 }}}

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:12 teor]:
 > I'll review this later today, after I get some Rust done.
 >
 > Do we want a consensus parameter to block Tor2web at Intros, like the
 one at Rendezvous?
 > I think the answer is "yes, but not on by default, and not on right now,
 and maybe just in 0.3.4".
 > I opened #25371 to do it in a separate task.

 Yes I think ultimately (hopefully 034 imo), we come down to rejecting
 single hop client for any part of the HS dance (single onion or not). Lets
 open a ticket for that at the RDV?

 I've modified the branch based on asn's comment to merge the suitable
 functions into one. I've renamed the function also to reflect a bit more
 what it is doing.

 See fixup `216c754e6f`.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 Good stuff! I am a bit confused about why the upgrade to binutils 2.30
 suddenly needs all those `nsis` related build changes. I mean the
 hardening flags are not really changing just with the binutils update...
 So, what's up with that?

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by brade):

 Replying to [comment:61 antonela]:
 > Thanks @mcs for the explainer.
 > So, in that case, my recommendation is to use a select

 Hi Antonela.  I think you misunderstand what we need your help with (and I
 apologize that you are coming in at the end of the process and working
 with someone else's design).

 We need help with the words that appear next to the radio button and the
 words that appear in the button (see image in comment:56).

 Linda's UX design and the implementation by Isis do not intend for the
 user to choose among the bridges returned from the BridgeDB server, so a
 select control would not be appropriate.  Each time the user requests
 bridges (see steps below) they receive a set of three and all three are
 used at the same time (the tor deamon figures out which one to use).


 > About the captcha, will it show after the user selects which kind of
 bridge he wants?

 Here is the sequence of steps for displaying the captcha:
 * user selects the radio button (currently labeled "Request a Bridge")
 * user clicks the "Request a Bridge..." button
 * [network activity occurs to obtain and display the captcha]
 Here is what the captcha prompt looks like:
 https://trac.torproject.org/projects/tor/raw-attachment/ticket/23136/moat-
 Dec8-A-prompt.png

 The ASCII art in comment:59 happens after a correct solution for the
 captcha is submitted and a set of bridges is returned by the BridgeDB
 server.  If all of the bridges from BridgeDB stop working, the user can
 "Request a New Bridge" to ask for a new set (which replaces the previous
 set).

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by asn):

 Patch LGTM.

 Are we sure this is not gonna make single onion services (and tor2web
 clients) go crazy with reconnecting and end up hurting the network?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Right now, we provide links to CSV files that graphs are based on. But in
 some cases it requires non-trivial data wrangling skills to obtain the
 data in the graph, which is less usable than it could be.

 What we could do instead is generate CSV files based on the graph and
 selected parameters. This will enable users to quickly obtain the data in
 a graph and further process it using tools of their choice.

 I already wrote this code and deployed it but did not merge it yet. I'm
 going to post a branch in a minute. My plan is to merge later today.
 Rushing this a bit, because it's something that should still go into the
 February report.

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:14 asn]:
 > Are we sure this is not gonna make single onion services (and tor2web
 clients) go crazy with reconnecting and end up hurting the network?

 In theory, because the circuits are closed at the RP with the
 "TORPROTOCOL" reason, the client should pick a new rendezvous point.
 However, there is a good chance the tor2web client will just loop over all
 RPs it can find and try them all in a loop. That would need to be tested.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 Here's [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-25382 my task-25382 branch] that implements this
 feature.

 Changes are already deployed and can be tried out on
 https://metrics.torproject.org/ (just look out for "Download data as CSV."
 on the graph pages).

 Happy to make fixes before this goes into master later today.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by iwakeh):

 * reviewer:   => iwakeh


Comment:

 Taking a look :-)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 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:   |
-+--
 With #25382 soon being merged, we should consider whether we still want to
 provide:
  - [https://metrics.torproject.org/stats.html specifications of current
 CSV files] as well as
  - CSV files like https://metrics.torproject.org/stats/servers.csv.

 The main reason for removing them from the public interface is to reduce
 future maintenance effort. These files will still exist and we will still
 use them internally, we'd just not make them available for download
 anymore. The reduced maintenance effort mainly comes from not having to
 write similar specifications when adding new pre-aggregated CSV files.

 Note that the data will still be available via the "Download data as CSV."
 links on all graph pages. See #25382 for that.

 What reasons might exist for leaving these CSV files still available. Are
 people using them and cannot switch easily to the new, ad-hoc generated
 CSV files?

 If we decide to take these files down, we'll have to give users a
 reasonable heads-up. 1--2 months seems reasonable. We should announce that
 decision at least on stats.html and possibly in other places, 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] #25384 [- Select a component]: Caveat to note about TB on OpenBSD

[Tor Bug Tracker & Wiki]

#25384: Caveat to note about TB on OpenBSD
--+
 Reporter:  gman999   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  tor browser www
  |  openbsd
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The TB version on OpenBSD is behind (again), and a note with the install
 instructions at https://www.torproject.org/download/download-easy.html.en
 should note that the available version of TB on OpenBSD should be checked
 with:

 pkg_info -Q tor-browser

 If provided version is not the current TB version, it is not recommended.

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

Re: [tor-bugs] #25348 [Community/Relays]: Add instructions for OpenBSD, amend FreeBSD to also mention obfs4

[Tor Bug Tracker & Wiki]

#25348: Add instructions for OpenBSD, amend FreeBSD to also mention obfs4
--+
 Reporter:  attila|  Owner:  Nusenu
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gman999):

 Additionally, it makes sense to link the relay guide to the TDP wiki at
 https://wiki.torbsd.org/ as it contains a treasure trove of information
 related to Tor on the BSDs.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 Suggested by iwakeh and briefly discussed before opening this ticket:
 let's look into adding comments to these CSV files with a short copyright
 notice and minimal specification. The format should be self-explanatory in
 most cases. But it wouldn't hurt to write a sentence or two about that.
 Doesn't have to happen before merging, though.

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

[tor-bugs] #25385 [- Select a component]: updated chroot document to reference

[Tor Bug Tracker & Wiki]

#25385: updated chroot document to reference
--+
 Reporter:  gman999   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  chroot openbsd tor
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://www.torproject.org/download/download-unix.html.en currently links
 to a heavily dated chroot guide at
 https://trac.torproject.org/projects/tor/wiki/doc/OpenbsdChrootedTor.

 A current and operational document on chroot'g Tor on OpenBSD is located
 at https://wiki.torbsd.org/doku.php?id=en:openbsd-chroot.

 tia

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

Re: [tor-bugs] #25214 [Applications/Tor Browser]: Canvas data extraction should be allowed when *local* pdf.js is invoked

[Tor Bug Tracker & Wiki]

#25214: Canvas data extraction should be allowed when *local* pdf.js is invoked
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => ff60-esr


Comment:

 [comment:1 tom]:
 > In 60, my hope is that fixing this will fix that one also.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Did the 'possible censorship events' get lost
 ([https://metrics.torproject.org/userstats-relay-
 country.html?start=2018-01-01&end=2018-02-28&country=all&events=on
 example])?

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by brade):

 Replying to [comment:62 gk]:
 > ...
 > 4) `let proxySettings;` as we are using it later on
 > even if no proxy settings got specified should we initialize it somehow,
 say to `undefined`?

 It will be initialized to `undefined` because that is how JS works (and we
 rely on that fact in many places).

 > 5)
 > ...
 > Why do we have the `showBridgeDBBridges()` call here if we are not using
 BridgeDB bridges
 > (i.e. there aren't any to begin with)?

 The call to `showBridgeDBBridges();` is there because we want to remove
 any old bridge lines from the UI (it clears them if gBridgeDBBridges is
 undefined or empty). But to address your item 3) in comment:49 we will be
 removing this block of code.

 > 7)
 >
 > It might not matter much but is socks4 really the thing we should test
 first
 > (meaning the protocol we expect to get used in the majority of cases)
 when
 > creating the proxy URL?

 We just followed the order that is presented in the dropdown menu within
 the UI.

 > 9)
 >
 > Do we need a spec update or an updated link to the spec you gave in `tl-
 bridgedb.jsm`? 'type': 'moat client supported transports' got changed
 'type':'client-transports' etc.
 > So, https://github.com/isislovecruft/bridgedb/tree/fix/22871#requesting-
 bridges does
 > not have latest version it seems?

 Good catch. A better URL for the spec (which we will put in the source
 code) is:
 https://github.com/isislovecruft/bridgedb/#accessing-the-moat-interface

 We will also fix the other (minor) items that I did not mention above.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:3 karsten]:
 > Suggested by iwakeh and briefly discussed before opening this ticket:
 let's look into adding comments to these CSV files with a short copyright
 notice and minimal specification. The format should be self-explanatory in
 most cases. But it wouldn't hurt to write a sentence or two about that.
 Doesn't have to happen before merging, though.

 Timing is fine, the discussion about format and explanatory text might
 take a while.

 Starting suggestion:

 {{{
 ##
 ## The Tor Project
 ##
 # URL:
 #
 https://metrics.torproject.org/networksize.html?start=2017-11-30&end=2018-02-28
 # Parameters:
 #  networksize: start=2017-11-30 end=2018-02-28
 #
 # Legend:
 #  date: UTC date (-MM-DD) when relays or bridges have been listed as
 running.
 #  relays: average number on the given day.
 #  bridges: average number on the given day.
 #
 date,relays,bridges
 2017-11-30,6512,1955
 2017-12-01,6629,1959
 2017-12-02,6647,1963
 2017-12-03,6650,1976
 ...
 }}}

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:4 iwakeh]:
 > Did the 'possible censorship events' get lost
 ([https://metrics.torproject.org/userstats-relay-
 country.html?start=2018-01-01&end=2018-02-28&country=all&events=on
 example])?

 All fine, we don't display these for 'all users' only for separate
 countries, where things are fine.

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

[tor-bugs] #25386 [- Select a component]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 currently, it is not possible to call C Tor, directly or indirectly, from
 rust tests. one of the following must be done:

 1. provide rust stubs for all C functions that may be needed for tests
 (impractical)

 2. test rust functions from C (so we will have C tests calling Rust
 functions calling C functions)

 3. link C functions into rust doctests (preferred)

 4. never call C-using rust functions in tests (leads to poor test
 coverage, very bad)

 my branch https://cgit.alxu.ca/tor.git/commit/?h=fix-rust-tests implements
 option 3 poorly. this is a bad solution firstly because it is very ugly,
 and secondly because it does not properly pass the system linking
 arguments, e.g. -L/opt/ssl. thirdly, it may hide problems in or cause to
 be compiled incorrectly dependency crates.

 this ticket blocks a number of rust improvements, since of course we would
 like to actually test the improvements, and doctests are the best way to
 do it in rust.

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

Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
---+
 Reporter:  isis   |  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, tor-crypto,  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  Sponsor3-can
---+

Comment (by Hello71):

 I filed #25386 for tracking fixing rust tests.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 The suggestion there looks like a fine start. Without going into the
 details yet,
  - we'll have to see how to generate those lines in R using `write.csv` an
  - we'll be able to re-use quite some content from the current stats.html.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by brade):

 Replying to [comment:63 gk]:
 > Here comes another round:
 >
 > 11) "We allow response.data to be an array or object". What about
 > `response.errors`?

 The JSON API spec says that `errors` must be an array but `data` does not
 have to be an array (see http://jsonapi.org/format/#document-top-level).
 Isis implemented the `data` payload as an array, but we wanted to be
 robust and allow it to be an object (we can remove that code if you want
 us to do so; for a long time we did not have a server to talk to ;)

 > 12) Spec says 'error', yet we check for `response.errors`, typo?

 That was a typo in the spec which Isis has fixed.

 > 13) braces mix
 > ...

 We will fix this.

 > 14)  // Returns a promise that is fulfilled with an object that
 contains:
 >  // captchaImage
 >
 > Do you mean "image" here instead of "captchaImage"? I looked at the spec
 and thought this was another instance of the spec you linked to being
 outdated but then I saw `image` in `_parseFetchResponse()`. If so, could
 you order the attributes in the comment lines: `transport`, `image`, and
 `challenge` as outlined in the spec?

 Our code actually transforms `image` in the Moat response to
 `captchaImage` in the JS object that is created and returned. It was
 clearer to us to use a more descriptive name.  We will reorder the
 property names in the comment.

 >
 > 15)
 >
 > {{{
 >  * If there is no overlap between the type of bridge we requested
 and
 >  * the transports which BridgeDB supports, the response is the same
 except
 >  * the transport property will contain an array of supported
 transports:
 >  * ...
 >  * "transport": [ "TRANSPORT", "TRANSPORT", ... ],
 > }}}
 >
 > Really? The spec seems to say
 > ...

 This was a spec change that came about during some conversations we had
 with Isis. The comment we have is correct based on the current spec.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:32 gk]:
 > Good stuff! I am a bit confused about why the upgrade to binutils 2.30
 suddenly needs all those `nsis` related build changes. I mean the
 hardening flags are not really changing just with the binutils update...
 So, what's up with that?

 The reason is that binutils 2.25 added this change:
 {{{
 * PE binaries now once again contain real timestamps by default.  To
 disable
   the inclusion of a timestamp in a PE binary, use the --no-insert-
 timestamp
   command line option.
 }}}

 So we need to add the `--no-insert-timestamp` flag to make the build
 reproducible, which was not necessary with binutils 2.24.

 Alternatively, we could patch `ld/emultempl/pe.em` and change this line to
 make it false by default:
 {{{
 static bfd_boolean insert_timestamp = TRUE;
 }}}

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:7 karsten]:
 > The suggestion there looks like a fine start. Without going into the
 details yet,
 >  - we'll have to see how to generate those lines in R using `write.csv`
 and

 We need to use `write.table`, for example:

 {{{
 ## the data summary
 summary(y)
  dateusers   downturnsupturnslower
 upper
  2018-01-01: 1   Min.   :716.0   Mode :logical   Mode :logical   Min.
 :165.0   Min.   :1039
  2018-01-02: 1   1st Qu.:755.0   FALSE:58FALSE:581st
 Qu.:403.5   1st Qu.:1106
  2018-01-03: 1   Median :780.0   Median
 :455.0   Median :1173
  2018-01-04: 1   Mean   :778.9   Mean
 :444.1   Mean   :1179
  2018-01-05: 1   3rd Qu.:802.5   3rd
 Qu.:496.2   3rd Qu.:1225
  2018-01-06: 1   Max.   :858.0   Max.
 :593.0   Max.   :1584
  (Other)   :52


 # writing
 write("# some comments", file="data.csv")
 write("# some more comments", file="data.csv", append = TRUE)
 write.table(y, file="data.csv", append = TRUE, quote=FALSE, sep=",",
 row.names = FALSE)
 }}}

 Yields:
 {{{
 # some comments
 # some more comments
 date,users,downturns,upturns,lower,upper
 2018-01-01,787,FALSE,FALSE,369,1319
 2018-01-02,754,FALSE,FALSE,427,1268
 2018-01-03,791,FALSE,FALSE,485,1107
 2018-01-04,823,FALSE,FALSE,452,1119
 ...
 }}}

 >  - we'll be able to re-use quite some content from the current
 stats.html.

 True, shortened versions of these explanations.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-1.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-2.png" 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] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 v2 Intro:

 v2 Tor2web will extend to another intro point, and then succeed because
 it's no longer a single hop path.

 v2 Rendezvous:

 v2 single onion services retry failed rendezvous with a 3-hop path, so
 they should retry once.
 But we turned off retries to try to reduce the DDoS load.
 So I guess they will just fail.
 And then v2 Tor2web will try another rendezvous point, and eventually give
 up.
 But we turned off Tor2web at rendezvous points.

 So we should use one of these combination of rendezvous retry and Tor2web
 settings in the consensus:
 * banning Tor2web works, or
 * allowing Tor2web and at least 1 retry also works.

 But allowing Tor2web and with no retries will put extra load on the
 network from Tor2web / single onion service failures.

 v3:

 We never implemented any special retry behaviour for v3 single onion
 services, but that doesn't matter, because there is no v3 Tor2web.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-2.2.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-2.png" 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] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
+
 Reporter:  Hello71 |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * version:   => Tor: 0.3.2.1-alpha
 * component:  - Select a component => Core Tor/Tor
 * points:   => 1
 * milestone:   => Tor: 0.3.4.x-final
 * keywords:   => rust, tor-test
 * type:  enhancement => defect


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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Replying to [comment:16 teor]:
 > v2 Intro:
 >
 > v2 Tor2web will extend to another intro point, and then succeed because
 it's no longer a single hop path.

 The client will only extend if it thinks that the service isn't connected
 to the intro point.
 So maybe we shouldn't close intro circuits, but we should force them to
 extend instead?

 And then we can have an option for closing them as a DDoS defence.

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
+
 Reporter:  Hello71 |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Hello71 has a branch here: https://cgit.alxu.ca/tor.git/commit/?h=fix-
 rust-tests

 But it needs to inherit libraries and library flags from the Makefile,
 And it needs to build Rust with asan, if asan is turned on.

 We want to pass the `-Z sanitizer` flag to Rust:
 https://github.com/japaric/rust-san

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
+
 Reporter:  Hello71 |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_revision


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

Re: [tor-bugs] #25384 [Webpages/Website]: Caveat to note about TB on OpenBSD

[Tor Bug Tracker & Wiki]

#25384: Caveat to note about TB on OpenBSD
-+
 Reporter:  gman999  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor browser www openbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * component:  - Select a component => Webpages/Website


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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Isn't it better just to upgrade nsis to 3.x version which Tom uses?
 Hardening on Windows is harmless for all programs, except ancient crap.
 But if nsis has problems with ASLR, why do you add `--enable-reloc-
 section`? As you removed SSP, why `-lssp`?
 `+# the nsis build system expect all toolchain binaries to be in the same`
 *expects

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

Re: [tor-bugs] #25385 [Webpages/Website]: updated chroot document to reference

[Tor Bug Tracker & Wiki]

#25385: updated chroot document to reference
+
 Reporter:  gman999 |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  chroot openbsd tor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * component:  - Select a component => Webpages/Website


Comment:

 Putting this in website, in the meantime, I suggest you replace the wiki
 page with a link to the up to date guide.
 Anyone can edit the wiki.

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

Re: [tor-bugs] #25385 [Webpages/Website]: updated chroot document to reference

[Tor Bug Tracker & Wiki]

#25385: updated chroot document to reference
+
 Reporter:  gman999 |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  chroot openbsd tor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by gman999):

 Okay, so just to be clear since I don't know correct Trac protocol...

 I can empty the current page, replace it with our chroot guide and provide
 an href to our wiki page?

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

Re: [tor-bugs] #25385 [Webpages/Website]: updated chroot document to reference

[Tor Bug Tracker & Wiki]

#25385: updated chroot document to reference
+
 Reporter:  gman999 |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  chroot openbsd tor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Yes. And if you make a mistake, that's what history is for.

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

Re: [tor-bugs] #25029 [Webpages/Website]: Update torproject.org logo

[Tor Bug Tracker & Wiki]

#25029: Update torproject.org logo
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 Can we also update the colors in use to match the styleguide?

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

Re: [tor-bugs] #25029 [Webpages/Website]: Update torproject.org logo

[Tor Bug Tracker & Wiki]

#25029: Update torproject.org logo
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #24520 [Webpages/Blog]: Change menu capitalization on blog

[Tor Bug Tracker & Wiki]

#24520: Change menu capitalization on blog
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase lead image bottom spacing; reduce top spacing

[Tor Bug Tracker & Wiki]

#23022: Increase lead image bottom spacing; reduce top spacing
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #24187 [Webpages/Blog]: Reduce bullet spacing on blog

[Tor Bug Tracker & Wiki]

#24187: Reduce bullet spacing on blog
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #24439 [Webpages/Blog]: Update blog title tab

[Tor Bug Tracker & Wiki]

#24439: Update blog title tab
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #24440 [Webpages/Blog]: Match blog title post spacing to archive post title spacing

[Tor Bug Tracker & Wiki]

#24440: Match blog title post spacing to archive post title spacing
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * keywords:   => ux-team


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by antonela):

 Replying to [comment:64 brade]:
 > Replying to [comment:61 antonela]:
 > > Thanks @mcs for the explainer.
 > > So, in that case, my recommendation is to use a select
 >
 > Hi Antonela.  I think you misunderstand what we need your help with (and
 I apologize that you are coming in at the end of the process and working
 with someone else's design).
 >
 Yes.
 > We need help with the words that appear next to the radio button and the
 words that appear in the button (see image in comment:56).
 >
 > Linda's UX design and the implementation by Isis do not intend for the
 user to choose among the bridges returned from the BridgeDB server, so a
 select control would not be appropriate.  Each time the user requests
 bridges (see steps below) they receive a set of three and all three are
 used at the same time (the tor deamon figures out which one to use).
 >
 I see. Thanks a lot for sharing with me the technical background.
 > > About the captcha, will it show after the user selects which kind of
 bridge he wants?
 >
 > Here is the sequence of steps for displaying the captcha:
 > * user selects the radio button (currently labeled "Request a Bridge")
 > * user clicks the "Request a Bridge..." button
 > * [network activity occurs to obtain and display the captcha]
 > Here is what the captcha prompt looks like:
 https://trac.torproject.org/projects/tor/raw-attachment/ticket/23136/moat-
 Dec8-A-prompt.png
 >
 > The ASCII art in comment:59 happens after a correct solution for the
 captcha is submitted and a set of bridges is returned by the BridgeDB
 server.

 So basically, the flow is going to be as following

 
[[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-1.png)]]
 
[[Image(https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-2.png)]]

 > If all of the bridges from BridgeDB stop working, the user can "Request
 a New Bridge" to ask for a new set (which replaces the previous set).

 Honestly, I see the idea about to have double steps with a kind of
 rejection. But if this friction can improve the security, I'm in. IMO, the
 best label is the option A. Also, if at some point we want to offer a
 different source to get a bridge, it is easily extendible.

 I'm afraid that it could be converted into an infinite loop between not
 working bridges and request a new bridge button, which seems confusing.
 I'd like to review error user flows and see how they are working on with
 this iteration.

 Could we have a nightly build to reproduce locally? That could be useful
 :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25387 [Metrics/Website]: Add comment section to CSV file headers

[Tor Bug Tracker & Wiki]

#25387: Add comment section to CSV file headers
-+--
 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:   |
-+--
 From #25382:

 Starting suggestion:

 {{{
 ##
 ## The Tor Project
 ##
 # URL:
 #
 https://metrics.torproject.org/networksize.html?start=2017-11-30&end=2018-02-28
 # Parameters:
 #  networksize: start=2017-11-30 end=2018-02-28
 #
 # Legend:
 #  date: UTC date (-MM-DD) when relays or bridges have been listed as
 running.
 #  relays: average number on the given day.
 #  bridges: average number on the given day.
 #
 date,relays,bridges
 2017-11-30,6512,1955
 2017-12-01,6629,1959
 2017-12-02,6647,1963
 2017-12-03,6650,1976
 ...
 }}}

 We need to use write.table, for example:

 {{{
 ## the data summary
 summary(y)
  dateusers   downturnsupturnslower
 upper
  2018-01-01: 1   Min.   :716.0   Mode :logical   Mode :logical   Min.
 :165.0   Min.   :1039
  2018-01-02: 1   1st Qu.:755.0   FALSE:58FALSE:581st
 Qu.:403.5   1st Qu.:1106
  2018-01-03: 1   Median :780.0   Median
 :455.0   Median :1173
  2018-01-04: 1   Mean   :778.9   Mean
 :444.1   Mean   :1179
  2018-01-05: 1   3rd Qu.:802.5   3rd
 Qu.:496.2   3rd Qu.:1225
  2018-01-06: 1   Max.   :858.0   Max.
 :593.0   Max.   :1584
  (Other)   :52


 # writing
 write("# some comments", file="data.csv")
 write("# some more comments", file="data.csv", append = TRUE)
 write.table(y, file="data.csv", append = TRUE, quote=FALSE, sep=",",
 row.names = FALSE)
 }}}

 Yields:

 {{{
 # some comments
 # some more comments
 date,users,downturns,upturns,lower,upper
 2018-01-01,787,FALSE,FALSE,369,1319
 2018-01-02,754,FALSE,FALSE,427,1268
 2018-01-03,791,FALSE,FALSE,485,1107
 2018-01-04,823,FALSE,FALSE,452,1119
 ...
 }}}

 We'll be able to re-use quite some content from the current stats.html.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * priority:  Medium => High


Comment:

 There, I moved the comments discussion to a separate ticket: #25387.

 If I don't hear otherwise, I'll merge changes to master in an hour or so.

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Changes look ok and the csv files are very useful.  Currently, as all
 links to [https://metrics.torproject.org/stats.html stats.html] are gone,
 it might be hard for users to find explanations for the data in files.
 But, this will only be temporary (Thanks, for adding #25387!).

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

Re: [tor-bugs] #25381 [Core Tor/Tor]: Add crypto_rand_double_sign() in C and Rust

[Tor Bug Tracker & Wiki]

#25381: Add crypto_rand_double_sign() in C and Rust
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  2
 Reviewer:|Sponsor:  SponsorQ
--+
Changes (by catalyst):

 * cc: catalyst (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] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-

Comment (by karsten):

 Thanks for looking! I'll merge later today.

 Regarding explanations, I agree that users will need to make sense of
 these CSV files themselves, at least for now. But at least I made sure
 they're all in "wide" format which I believe is what most Excel users
 would expect. And R users can easily reformat files. And yes, #25387 will
 fix that.

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

[tor-bugs] #25388 [Core Tor/Tor]: document how to allow partially failing builds in Travis CI

[Tor Bug Tracker & Wiki]

#25388: document how to allow partially failing builds in Travis CI
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Sometimes configurations that fewer developers regularly build with get
 merged with changes that break our Travis CI builds.

 We should make it easier to temporarily allow those builds to fail while
 people work on getting them fixed, because sometimes it takes a while.
 This can include adding commented-out `allow_failure` clauses.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-11.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by antonela):

 * Attachment "BridgeDB-21.png" 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by antonela):

 Isabela and I we have been discussing this ticket and here is our final
 suggestion:

 1.1
 
https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-11.png
 {{{
 [X] Request a Bridge from torproject.org
[Request a Bridge]
 }}}

 1.2
 
https://trac.torproject.org/projects/tor/attachment/ticket/23136/BridgeDB-21.png
 {{{
 [X] Request a bridge from torproject.org
obfs4 1.2.3.4 fingerprint...
obfs4 1.2.3.5 fingerprint...
obfs4 1.2.3.6 fingerprint...
[Request a New Bridge…]
 }}}


 We hope we can test it with users soon to validate all these assumptions.
 Also, if any build is available to download, please let us know. 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] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:17 teor]:
 > Replying to [comment:16 teor]:
 > > v2 Intro:
 > >
 > > v2 Tor2web will extend to another intro point, and then succeed
 because it's no longer a single hop path.
 >
 > The client will only extend if it thinks that the service isn't
 connected to the intro point.
 > So maybe we shouldn't close intro circuits, but we should force them to
 extend instead?

 In theory, just a NACK received by the client will make it reuse the
 circuit and re-extend. See `handle_introduce_ack()`. This patch makes the
 intro return `HS_CELL_INTRO_ACK_NORELAY` which triggers a re-extend. Same
 goes for v2 in `rend_client_introduction_acked()`.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by brade):

 Replying to [comment:68 antonela]:
 > Isabela and I we have been discussing this ticket and here is our final
 suggestion:
 > ...

 Thank you for the quick turnaround!

 One clarifying question:  Is there a reason you omitted the ellipsis
 ('...') from the button?  Historically that has been used when the user
 will need to provide more information to complete the action (in this
 case, they will need to answer the captcha).

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

Re: [tor-bugs] #25333 [Applications/Tor Browser]: NOT SECURE CONECTION please help

[Tor Bug Tracker & Wiki]

#25333: NOT SECURE CONECTION please help
--+---
 Reporter:  kiokawasaki1998   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by phshirk):

 it was kaspersky

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

Re: [tor-bugs] #25388 [Core Tor/Tor]: document how to allow partially failing builds in Travis CI

[Tor Bug Tracker & Wiki]

#25388: document how to allow partially failing builds in Travis CI
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Proposed patch in my github repo as bug25388-025.  It should merge cleanly
 to all supported releases and master.

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

Re: [tor-bugs] #25308 [Core Tor/Tor]: Onion service node pinning by default

[Tor Bug Tracker & Wiki]

#25308: Onion service node pinning by default
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * keywords:   => tor-hs
 * component:  Core Tor => Core Tor/Tor
 * milestone:   => Tor: unspecified


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

[tor-bugs] #25389 [Applications/Tor Browser]: backport Subprocess.jsm runaway CPU fix (Mozilla 1370027)

[Tor Bug Tracker & Wiki]

#25389: backport Subprocess.jsm runaway CPU fix (Mozilla 1370027)
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #24689
   Points:|   Reviewer:
  Sponsor:  Sponsor4  |
--+--
 It turns out that the Moat runaway CPU issue that gk reported (see
 ticket:23136#comment:53) is something that Mozilla already found. To fix
 it in Tor Browser, we need to backport the "Part 1" patch from
 https://bugzilla.mozilla.org/show_bug.cgi?id=1370027.

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

Re: [tor-bugs] #25293 [- Select a component]: tor router in raspberry pi3

[Tor Bug Tracker & Wiki]

#25293: tor router in raspberry pi3
--+
 Reporter:  osos  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  - Select a component  |Version:  Tor: 0.2.9.12
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor router|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Hi,

 You need to run your tor as `root` user to be able to bind to port 53.

 Furthermore, it seems something is already running on port 9040 and 9050
 which explains the:

 {{{
 Feb 18 05:57:19.783 [warn] Could not bind to 192.168.42.1:9040: Address
 already in use. Is Tor already running?
 }}}

 I think you should see if tor is already running, killing it and using
 root to be able to bind to 53.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by mcs):

 Replying to [comment:53 gk]:
 > Replying to [comment:50 gk]:
 > > 5) If I just used moat once I have afterwards a firefox process
 running at 150% CPU-wise regardless whether I am using bridges let alone
 requesting new ones. It's just "doing" things and is not going away or
 down to reasonable values.
 >
 > Steps to reproduce:
 > ...

 After much debugging and then reviewing recent Mozilla changes to the code
 under toolkit/modules/subprocess/, Kathy and I found the culprit. I just
 filed a new ticket: #25389.

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

Re: [tor-bugs] #25389 [Applications/Tor Browser]: backport Subprocess.jsm runaway CPU fix (Mozilla 1370027)

[Tor Bug Tracker & Wiki]

#25389: backport Subprocess.jsm runaway CPU fix (Mozilla 1370027)
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--
Changes (by mcs):

 * keywords:   => TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 The Mozilla patch applied cleanly to ESR52 without any changes. Here is
 the patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug25389-01

 Kathy and I tested this on Linux and macOS (the changes should not affect
 Windows), and confirmed that the runaway CPU problem is indeed fixed. We
 never reproduced the problem on macOS but it was easy to get it to occur
 on Linux.

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

Re: [tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
--+---
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by justmeee):

 * priority:  Medium => Immediate
 * severity:  Normal => Critical


Comment:

 It crashed today while working on it.  Also, the trick of having two
 windows open doesn't work as well as I though it was.

 I was able to copy the log from the screen today when it crashed:

 Problem signature:
   Problem Event Name:   APPCRASH
   Application Name: firefox.exe
   Application Version:  52.6.0.6607
   Application Timestamp:
   Fault Module Name:mozglue.dll
   Fault Module Version: 52.6.0.6607
   Fault Module Timestamp:   
   Exception Code:   c005
   Exception Offset: 34a7
   OS Version:   6.1.7601.2.1.0.256.48
   Locale ID:1033
   Additional Information 1: 0a9e
   Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
   Additional Information 3: 0a9e
   Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

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

Re: [tor-bugs] #25257 [Applications/Orbot]: Orbot relay problem.

[Tor Bug Tracker & Wiki]

#25257: Orbot relay problem.
+--
 Reporter:  bogus   |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:  Tor: 0.3.2.9
 Severity:  Critical| Resolution:
 Keywords:  Relay   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  bogus   |Sponsor:  Sponsor3
+--
Changes (by dgoulet):

 * cc: Atlas (removed)
 * actualpoints:  222 =>
 * component:  Core Tor/Tor => Applications/Orbot
 * priority:  Immediate => Medium
 * points:  1 =>
 * milestone:  Tor: unspecified =>
 * owner:  (none) => n8fr8


Comment:

 I bet the port 443 requires admin privileges and maybe Orbot doesn't get
 them?...

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

Re: [tor-bugs] #25382 [Metrics/Website]: Make all graph data available as CSV

[Tor Bug Tracker & Wiki]

#25382: Make all graph data available as CSV
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Merged. We'll take care of the rest in other tickets. Closing. Thanks!

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

Re: [tor-bugs] #25229 [- Select a component]: Resist Spectre by using retpoline and a new instruction provided by Intel with microcode update

[Tor Bug Tracker & Wiki]

#25229: Resist Spectre by using retpoline and a new instruction provided by 
Intel
with microcode update
--+-
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dgoulet):

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


Comment:

 Firefox has introduced defenses for this so it will get in Tor Browser at
 some point.

 As for Tor, the OS kernel should be the main actor to mitigate those which
 by now updates have been rolled out on all major OS.

 Unless there is a concrete way to implement a defense in tor itself,
 please open a ticket specifically pointing to that for which we can have
 action items.

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

Re: [tor-bugs] #25257 [Applications/Orbot]: Orbot relay problem.

[Tor Bug Tracker & Wiki]

#25257: Orbot relay problem.
+--
 Reporter:  bogus   |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:  Tor: 0.3.2.9
 Severity:  Critical| Resolution:
 Keywords:  Relay   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  bogus   |Sponsor:  Sponsor3
+--

Comment (by n8fr8):

 Yes, you need root to run a port below 1000, and Orbot doesn't have root.

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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 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 karsten):

 * cc: irl (added)


Comment:

 irl, I vaguely remember that you were planning to use the stats/*.csv
 files for something related to metrics-bot. What was that, and would that
 also work with the new graph-based CSV files?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25390 [Core Tor/Tor]: Tor browser fails when external tor instance is configured

[Tor Bug Tracker & Wiki]

#25390: Tor browser fails when external tor instance is configured
--+
 Reporter:  Zedfour   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I have configured Tor browser to use an independent Tor instance in my
 local network by changing the SOCKS5 proxy. Problem is, if there is such
 instance configured in Tor browser's Network settings, the startup will
 fail next time, since the included instance can not start listening on an
 interface that does not exist on the local machine.

 Also, if I want to do the same with an instance running on the local
 machine, the included instance will also fail to start due to port
 conflict. Is there a correct way to do this?

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

Re: [tor-bugs] #25390 [Core Tor/Tor]: Tor browser fails to start when configured to use an external tor instance (was: Tor browser fails when external tor instance is configured)

[Tor Bug Tracker & Wiki]

#25390: Tor browser fails to start when configured to use an external tor 
instance
--+
 Reporter:  Zedfour   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
--+---
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:13 justmeee]:
 Usually it's just a signature of suicide of a child process when the
 parent process crashed. You can find out what's happened in Windows Event
 Viewer.

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

Re: [tor-bugs] #25229 [Applications/Tor Browser]: Resist Spectre by using retpoline and a new instruction provided by Intel with microcode update

[Tor Bug Tracker & Wiki]

#25229: Resist Spectre by using retpoline and a new instruction provided by 
Intel
with microcode update
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  closed => reopened
 * resolution:  invalid =>
 * component:  - Select a component => Applications/Tor Browser
 * keywords:   => tbb-security


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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+--
Changes (by igt0):

 * status:  needs_revision => needs_review


Comment:

 I followed the same approach in the #25260, torbutton will work as a
 feature extension, so we still need to change the browser adding it as a
 subdirectory(git submodule?).
 The changes in the tor button are related to the build system and making
 it work with the mozilla central code base(few things changed and others
 are deprecated).

  **bug 25013: Add Gecko build system infrastructure into tor button**
 
https://github.com/igortoliveira/torbutton/commit/ef153a43363ee0714f6187b545494161bea96610

  **bug 25013: Migrate general.useragent.locale to intl.locale.requested **
 
https://github.com/igortoliveira/torbutton/commit/40682676e33570d464534adc07bf94acb36a76fe

  **bug 25013: Update deprecated JS code**
 
https://github.com/igortoliveira/torbutton/commit/1b50773f87465643ab8aed8104fa0c9a0fa5e0f5

  **bug 25013: Update XPCOM calls after changes in the interfaces**
 
https://github.com/igortoliveira/torbutton/commit/a35a746ca206706f4c5742d70bc90b649c1bfdf0

 Replying to [comment:19 gk]:
 > FWIW: I can see us copying over files from the Torbutton repo or just
 package up an .xpi and put the extracted files into tor-browser.git before
 we tag (and use the machinery developed in some of the patches above). I
 just think that step 1 of the migration should not contain getting rid of
 the Torbutton repo. We should do this once we integrate the components we
 need tighter into the browser. I guess this would be a thing, at some
 point, for step 3 in Arthur's staged approach.

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

Re: [tor-bugs] #22689 [Core Tor/Tor]: hs: Stop rend and intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop rend and intro points being used as single hop proxies
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  relay-safety  |  Actual Points:
Parent ID:  #17945| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Ok, let's put these behind DDoS options that are on by default, so we can
 turn them off if we get it wrong.

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

Re: [tor-bugs] #25257 [Applications/Orbot]: Orbot relay problem.

[Tor Bug Tracker & Wiki]

#25257: Orbot relay problem.
+--
 Reporter:  bogus   |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:  Tor: 0.3.2.9
 Severity:  Critical| Resolution:  not a bug
 Keywords:  Relay   |  Actual Points:
Parent ID:  | Points:
 Reviewer:  bogus   |Sponsor:  Sponsor3
+--
Changes (by teor):

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


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

Re: [tor-bugs] #25390 [Applications/Tor Browser]: Tor browser fails to start when configured to use an external tor instance

[Tor Bug Tracker & Wiki]

#25390: Tor browser fails to start when configured to use an external tor 
instance
--+
 Reporter:  Zedfour   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:  (none) => tbb-team
 * resolution:   => worksforme
 * status:  new => closed
 * component:  Core Tor/Tor => Applications/Tor Browser


Comment:

 Yes, there are environmental variables that can be used to control Tor
 Launcher.
 Please see the Tor Launcher documentation for details.

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

Re: [tor-bugs] #25388 [Core Tor/Tor]: document how to allow partially failing builds in Travis CI

[Tor Bug Tracker & Wiki]

#25388: document how to allow partially failing builds in Travis CI
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-+--
 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:
-+--

Comment (by joss):

 I might be almost unique in this, but I do actively use the existing full
 user metric .csv files for the infolabe-anomalies mailing list
 (). This is
 carrying out anomaly detection on a nightly basis looking at user numbers.

 I'm not entirely sure to what extent this data would still be available
 under the proposed change. I'm fine to update my code a bit to change
 URLs, etc, but if the data disappeared entirely it would harm some of my
 research quite considerably.

 In a more general sense, I'd strongly advocate for an 'open data'
 principle. You never know what research the next person coming along might
 do, and what it might contribute. At the moment it's a simple curl/wget to
 get that data -- if I had to wrangle a web interface as a precondition to
 carrying out analysis on Tor metrics then it would (possibly) be extremely
 awkward.

 Again, though, maybe I'm misunderstanding the proposed changes.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:33 boklm]:
 > Replying to [comment:32 gk]:
 > > Good stuff! I am a bit confused about why the upgrade to binutils 2.30
 suddenly needs all those `nsis` related build changes. I mean the
 hardening flags are not really changing just with the binutils update...
 So, what's up with that?
 >
 > The reason is that binutils 2.25 added this change:
 > {{{
 > * PE binaries now once again contain real timestamps by default.  To
 disable
 >   the inclusion of a timestamp in a PE binary, use the --no-insert-
 timestamp
 >   command line option.
 > }}}
 >
 > So we need to add the `--no-insert-timestamp` flag to make the build
 reproducible, which was not necessary with binutils 2.24.

 I understand that part and that's not the thing that confuses me. Before
 the patch we had
 "# remove hardening wrappers" but now we have "# Some of the hardening
 flags are causing the build to fail, so we overwrite the helpers with only
 the flags required to make the build reproducible." So, why do we have
 suddenly the need for the hardening option `-Wl,--enable-reloc-section`?
 Just because we need to deal with `--no-insert-timestamp`?

 > Alternatively, we could patch `ld/emultempl/pe.em` and change this line
 to make it false by default:
 > {{{
 > static bfd_boolean insert_timestamp = TRUE;
 > }}}

 I think we don't want that.

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

Re: [tor-bugs] #25334 [Applications/Tor Mail]: Missing SearchAPI.h on Windows builds of Thunderbird when cross-compiling on Linux

[Tor Bug Tracker & Wiki]

#25334: Missing SearchAPI.h on Windows builds of Thunderbird when 
cross-compiling
on Linux
---+
 Reporter:  sukhbir|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Mail  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by sukhbir):

 I added the headers and that seems to resolve this issue (as expected) but
 there seems to be more than one missing headers here. So I opened
 https://bugzilla.mozilla.org/show_bug.cgi?id=1442034 and reported it there
 to see what is the correct way of fixing this (and subsequent missing
 headers) since it involves adding the headers from from the Windows SDK to
 mingw-w64.

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201802,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:35 gk]:
 >
 > I understand that part and that's not the thing that confuses me. Before
 the patch we had
 > "# remove hardening wrappers" but now we have "# Some of the hardening
 flags are causing the build to fail, so we overwrite the helpers with only
 the flags required to make the build reproducible." So, why do we have
 suddenly the need for the hardening option `-Wl,--enable-reloc-section`?
 Just because we need to deal with `--no-insert-timestamp`?

 Ah, I think we only need `--no-insert-timestamp` and not the other
 options. I will make a new revision of the patch keeping only `--no-
 insert-timestamp`.

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

Re: [tor-bugs] #25229 [Applications/Tor Browser]: Resist Spectre by using retpoline and a new instruction provided by Intel with microcode update

[Tor Bug Tracker & Wiki]

#25229: Resist Spectre by using retpoline and a new instruction provided by 
Intel
with microcode update
--+-
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 FF52 isn't impacted, if there's something that needs to be implemented to
 better resist those nasty bugs then Mozilla will make a new FF52 ESR
 release.

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

Re: [tor-bugs] #25386 [Core Tor/Tor]: fix rust tests

[Tor Bug Tracker & Wiki]

#25386: fix rust tests
+
 Reporter:  Hello71 |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  High|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  rust, tor-test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by Hello71):

 * status:  needs_revision => needs_review


Comment:

 still doesn't work with --enable-fragile-hardening due to ubsan, might
 work if that's commented out (or maybe not?)

 I still think the best way is to build a "libtor.so" and link all the
 tests with it, so we don't have to pass all the dependencies in or
 interrogate the toolchain about how to link sanitizers.

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

Re: [tor-bugs] #25301 [Applications/Tor Browser]: Sometimes right after NI typing a website and clicking on enter on landing about:tor won't load it no matter how much time is given

[Tor Bug Tracker & Wiki]

#25301: Sometimes right after NI typing a website and clicking on enter on 
landing
about:tor won't load it no matter how much time is given
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Original reporter here: I have been unable to further reproduce this. I
 guess it's just one of those rare bugs.

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