Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 Test failure:
 {{{
 [junit] Testcase: testIgnoreFuture took 0.392 sec
 [junit] FAILED
 [junit] expected:<1> but was:<0>
 [junit] junit.framework.AssertionFailedError: expected:<1> but was:<0>
 [junit] at
 
org.torproject.onionoo.writer.BandwidthDocumentWriterTest.testIgnoreFuture(BandwidthDocumentWriterTest.java:74)
 }}}

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

Re: [tor-bugs] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 To all of you who feel the urge to reopen this bug again, please resist
 and keep this bug closed, 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] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:17 nickm]:
 > Oh!  Actually, fragile-hardening does make some code extremely slow, and
 the sha3 code might be one such code.  Do you get the same result without
 it?

 Interesting. So far it looks good. I'll keep testing a bit more, though,
 to be on the safe side.

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

Re: [tor-bugs] #24421 [Applications/Tor Browser]: "Temporarily allow all this page" and uploads get inherited when New Identity is chosen.

[Tor Bug Tracker & Wiki]

#24421: "Temporarily allow all this page" and uploads get inherited when New
Identity is chosen.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-newnym, TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: ma1 (added)


Comment:

 Giorgio: Any ideas on that one?

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

Re: [tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-disk-leak


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24868 [Core Tor/Tor]: Check a consensus parameter before activating onion service IPv6 features

[Tor Bug Tracker & Wiki]

#24868: Check a consensus parameter before activating onion service IPv6 
features
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  prop224, tor-hs, single-onion, ipv6
Actual Points:   |  Parent ID:  #23493
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 We've implemented #23577, but it looks like none of the other onion
 service IPv6 code will be ready for 0.3.3.

 (We want to do the relay IPv6 code first.)

 If we merge this in 0.3.3, then services will be able to distinguish 0.3.2
 and 0.3.3 (and later) clients, when the rend point is dual-stack.

 Do we want to add a torrc option / consensus parameter for v3 onion
 service IPv6? Or are we happy with this information leak?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24867 [Core Tor/Tor]: Do relays keep more than one canonical connection when they extend over IPv6?

[Tor Bug Tracker & Wiki]

#24867: Do relays keep more than one canonical connection when they extend over
IPv6?
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay
Actual Points:|  Parent ID:  #24403
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 We should find out, and fix any issues.

 The warnings would look something like #24841.

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
--+
 Reporter:  tyng  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.8-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 mikeperry]:
 > My guess is that this relay has both IPv4 and IPv6 connections to some
 of its peers. Options include A) checking for that and not logging in that
 case. B) Marking one of these duplicate connections as non-canonical, so
 the duplicates won't persist.

 Relays do not extend over IPv6, so this explanation is unlikely. IPv6
 relay extends will be implemented in #24404.

 My guess is that the canonical connection code behaves badly under load.

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 My relays are running 0.3.0 with a backport for #24666, they topped out at
 7 GB before I started restricting incoming connections. So there may not
 be any memory leak here.

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

Re: [tor-bugs] #24421 [Applications/Tor Browser]: "Temporarily allow all this page" and uploads get inherited when New Identity is chosen.

[Tor Bug Tracker & Wiki]

#24421: "Temporarily allow all this page" and uploads get inherited when New
Identity is chosen.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-newnym, TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Another idea came to me while I was doing something else: maybe there are
 actually two copies of the NoScript code running, and *that* is causing
 problems. A quick `dump()` added to the end of NoScript's Main.js shows it
 is being loaded twice, but I am not sure if that is by design or not.

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

Re: [tor-bugs] #24865 [Metrics/Consensus Health]: Use icons on Consensus Health

[Tor Bug Tracker & Wiki]

#24865: Use icons on Consensus Health
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by irl):

 How would you plan to use them? There's an icon font and a series of
 different sized PNGs. The originals are SVGs.

 Apparently I made a Git repository that I have just discovered at
 https://gitweb.torproject.org/user/irl/tor-icons.git/tree/. The download
 from the webpage contains all the assets though, you probably won't need
 the repo.

 The drawback to using an icon font is it won't work in TBB high security
 mode. This may or may not be important, as the icons are only used to make
 it look cool and not used to convey additional meaning.

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

Re: [tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "history-search.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

[tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 My Tor Browser has two entries in the `moz_historyvisits` table in
 places.sqlite. The two URLs can come up during URL bar autocompletion, and
 also appear in the ctrl+H history window.

 I noticed it just now when I saw URL bar autocompletions for URLs that
 were not bookmarks and were not open tabs. Here is a screenshot. The first
 three matches are bookmarks, as you can tell by the star icon. The
 accounts.google.com one is not a bookmark, but is for some reason being
 remembered across restarts.

 [[Image(blog-autocomplete.png)]]

 The two URLs that are being remembered are:
  *
 !https://accounts.google.com/ServiceLogin?continue=https://www.blogger.com
 /comment-
 
iframe.g?blogID%3D2266550428847361277%26postID%3D6186454555221678264%26blogspotRpcToken%3D3273703%26bpli%3D1&followup=https://www.blogger.com
 /comment-
 
iframe.g?blogID%3D2266550428847361277%26postID%3D6186454555221678264%26blogspotRpcToken%3D3273703%26bpli%3D1&passive=true&go=true#%7B%22color%22%3A%22rgb(110%2C%20110%2C%20110)%22%2C%22backgroundColor%22%3A%22rgb(204%2C%20204%2C%20204)%22%2C%22unvisitedLinkColor%22%3A%22rgb(0%2C%200%2C%200)%22%2C%22fontFamily%22%3A%22Verdana%2CGeneva
 %2Csans-serif%22%7D
  *
 
!https://id.rlcdn.com/463496.gif?credir=https%3A%2F%2Fsimage4.pubmatic.com%2FAdServer%2FSPug%3Fo%3D3%26u%3D1292AC75-4860
 -4D0E-
 
8AC2-F720B90009E0%26vcode%3Dbz0yJnR5cGU9MSZjb2RlPTMzMzkmdGw9MTI5NjAw%26piggybackCookie%3D&redirect=1
 The first one kind of makes sense. If I click on it, it takes me to a
 comment field for the [https://breakwa11.blogspot.com/ blog of BreakWa11],
 a circumvention developer whose blog I have visited in the past few
 months. It's not a top-level page though; seems like it belongs in an
 iframe. The other one looks like an advertising tracking pixel (hope it's
 nothing personal lol).

 I found where the URLs are being stored: they are in the
 [http://kb.mozillazine.org/Places.sqlite places.sqlite] database, in the
 `moz_places` table:
 {{{
 $ sqlite3 tor-browser_en-
 US/Browser/TorBrowser/Data/Browser/profile.default/places.sqlite
 SQLite version 3.21.0 2017-10-24 18:55:49
 Enter ".help" for usage hints.
 sqlite> select * from moz_places;
 [elided other entries which are my bookmarks]
 68|https://accounts.google.com/ServiceLogin?continue=https://www.blogger.com
 /comment-
 
iframe.g?blogID%3D2266550428847361277%26postID%3D6186454555221678264%26blogspotRpcToken%3D3273703%26bpli%3D1&followup=https://www.blogger.com
 /comment-
 
iframe.g?blogID%3D2266550428847361277%26postID%3D6186454555221678264%26blogspotRpcToken%3D3273703%26bpli%3D1&passive=true&go=true#%7B%22color%22%3A%22rgb(110%2C%20110%2C%20110)%22%2C%22backgroundColor%22%3A%22rgb(204%2C%20204%2C%20204)%22%2C%22unvisitedLinkColor%22%3A%22rgb(0%2C%200%2C%200)%22%2C%22fontFamily%22%3A%22Verdana%2CGeneva
 %2Csans-
 
serif%22%7D||moc.elgoog.stnuocca.|1|1|0||-1|1510963636686206|jljYEjVwHSTz|0|47357881751906
 [elided]
 
71|https://id.rlcdn.com/463496.gif?credir=https%3A%2F%2Fsimage4.pubmatic.com%2FAdServer%2FSPug%3Fo%3D3%26u%3D1292AC75-4860
 -4D0E-
 
8AC2-F720B90009E0%26vcode%3Dbz0yJnR5cGU9MSZjb2RlPTMzMzkmdGw9MTI5NjAw%26piggybackCookie%3D&redirect=1||moc.ndclr.di.|1|1|0||-1|1513646987292092|AG
 --rmyoEVB2|0|47360465205581
 [elided]
 }}}

 These two entries with `id=68` and `id=71` are referenced in the
 `moz_historyvisits` table. Here is the whole table:
 {{{
 sqlite> select * from moz_historyvisits;
 1|0|68|1510963636686206|6|0
 2|0|71|1513646987292092|6|0
 }}}
 The fourth column looks like a microsecond timestamp, and the one for
 BreakWa11's blog matches the time frame during which I would have visited
 the site.
 {{{
 $ date -u -d @1510963636.686206
 Sat Nov 18 00:07:16 UTC 2017
 $ date -u -d @1513646987.292092
 Tue Dec 19 01:29:47 UTC 2017
 }}}

 The `moz_historyvisits` table seems to underlie the ctrl+H history window.
 When I open it, there are two entries corresponding to the months of the
 timestamps. However it doesn't list any URLs: if I click the expander
 arrows, the arrows just disappear without expanding anything. But if I
 search for a string like "http", I can make the URLs appear.

 [[Image(history-default.png)]] [[Image(history-search.png)]]

 Ticket #23704 is potentially related; it's about the browser remembering
 tabs after upgrading. comment:3:ticket:23704 says "TBB 7.0.5/6 has
 `places.h

Re: [tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "blog-autocomplete.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] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "history-default.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

[tor-bugs] #24865 [Metrics/Consensus Health]: Use icons on Consensus Health

[Tor Bug Tracker & Wiki]

#24865: Use icons on Consensus Health
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 We apparently have some sweet icons now:
 https://people.torproject.org/~irl/icons/

 We should use them!!

 irl, antonela: Are these icons baked, all set, and ready to go?  Or should
 I wait until some future point where they are 'done'.

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

Re: [tor-bugs] #24818 [Core Tor/Tor]: Make the hard-coded authorities into a separate include file with a standard format

[Tor Bug Tracker & Wiki]

#24818: Make the hard-coded authorities into a separate include file with a
standard format
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  torspec, tor-dirauth  |  Actual Points:
Parent ID:  #24786| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by beastr0):

 * cc: beastr0@… (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] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 025-backport,  |  Actual Points:
  029-backport, 030-backport, 031-backport,  |
  032-backport   |
Parent ID:  #24818   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by beastr0):

 * cc: beastr0@… (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] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by starlight):

 quiet so far, have HSDIR again but no evidence of a popular onion service,
 rating backup up though not to previous max; no severe attacks

 if this ticket has sent them off I could, on the next shutdown, gdb-attach
 the daemon with a breakpoint just before exit() and call malloc_stats();
 will yield an indication on leak vs fragmentation;  daemon was definitely
 exhibiting errant memory behavior when first started per comment:6
 (holding steady at present); would take cores for further analysis

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 copy from
 ​https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html

 Hi,

 the goal of this email is to avoid a false positive warning for relay
 operators
 on atlas but the root cause might be in core tor.

 background:
 I really liked when irl added the big red warning to atlas when a tor
 relay
 runs an outdated (aka not running a "recommended") tor version
 because it actually triggered operators to upgrade, an important step
 toward a more healthy network.
 The problem is: This big red banner on atlas has false-positives which
 confuses operators [0].

 Originally this has been an onionoo bug which
 has been fixed in v1.8.0, but it happens again and Karsten had the feeling
 that tor dir auths do not update  the version information of a relay after
 it
 upgraded (and uploaded a new descriptor). I looked into one example and
 can confirm what Karsten suggested [1].

 Let me show you that example of FP
 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
 Data has been provided by Karsten and is available here: [2].

 That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his
 first
 descriptor with 0.3.0.13 on:

 2018-01-09 10:14:00,server,,0.3.0.13

 except for bastet dir auths did not care and still said this relay runs
 0.3.0.10:

 2018-01-09 11:00:00,consensus,,0.3.0.10
 2018-01-09 11:00:00,vote,bastet,0.3.0.13   note
 2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 11:00:00,vote,dizum,0.3.0.10
 2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 11:00:00,vote,longclaw,0.3.0.10
 2018-01-09 11:00:00,vote,maatuska,0.3.0.10
 2018-01-09 11:00:00,vote,moria1,0.3.0.10
 2018-01-09 11:00:00,vote,tor26,0.3.0.10
 2018-01-09 12:00:00,consensus,,0.3.0.10
 2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<
 2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 12:00:00,vote,dizum,0.3.0.10
 2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 12:00:00,vote,longclaw,0.3.0.10
 2018-01-09 12:00:00,vote,maatuska,0.3.0.10
 2018-01-09 12:00:00,vote,moria1,0.3.0.10
 2018-01-09 12:00:00,vote,tor26,0.3.0.10

 even 6 hours later this is unchanged.

 Then the operator upgraded from 0.3.0.13 to 0.3.1.9
 and uploaded his first descriptor:

 2018-01-09 16:39:01,server,,0.3.1.9

 this remained "unnoticed" by all dir auths until
 longclaw voted for the new version:

 2018-01-09 23:00:00,consensus,,0.3.0.10
 2018-01-09 23:00:00,vote,bastet,0.3.0.10
 2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 23:00:00,vote,dizum,0.3.0.10
 2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <
 2018-01-09 23:00:00,vote,maatuska,0.3.0.10
 2018-01-09 23:00:00,vote,moria1,0.3.0.10
 2018-01-09 23:00:00,vote,tor26,0.3.0.10

 On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
 v0.3.1.9 and almost all dir auths agreed immediately:

 2018-01-10 02:38:07,server,,0.3.1.9
 2018-01-10 03:00:00,consensus,,0.3.1.9
 2018-01-10 03:00:00,vote,bastet,0.3.0.10
 2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
 2018-01-10 03:00:00,vote,dizum,0.3.1.9
 2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
 2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
 2018-01-10 03:00:00,vote,longclaw,0.3.1.9
 2018-01-10 03:00:00,vote,maatuska,0.3.1.9
 2018-01-10 03:00:00,vote,moria1,0.3.1.9
 2018-01-10 03:00:00,vote,tor26,0.3.1.9


 So it took the operator 17 hours to convince enough
 dir auths that he upgraded.
 I can see multiple reasons why this can make sense (as the tor version
 is actually not that relevant consensus data) but maybe it was
 not clear what the side effects of not updating that field are.

 While I believe there is still another onionoo issue,
 this should also be improved.

 Thoughts?



 [0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
 [1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
 [2]
 https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488
 -relay-versions.csv.gz


 #24862 aims to help track and debug 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] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Hey, why Tor Browser can't have one or two checkbox?

 {{{
 [*] Show Insecure warning when known corporate MITM is detected

 If checked, the browser will show a warning(just like self-sign
 certificate)
 Padlock icon = yellow exclamation mark
 Padlock detail = /!\ This page is behind corporate MITM attack
 }}}

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

Re: [tor-bugs] #24812 [Webpages/Website]: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists only two

[Tor Bug Tracker & Wiki]

#24812: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists 
only
two
--+
 Reporter:  cypherpunks   |  Owner:  kat5
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

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


Comment:

 Merged! Thanks.

 (I wonder what the third used to be.)

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

Re: [tor-bugs] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 We already have #18361 and #24321. Closing this as duplicate.

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:266 cypherpunks]:
 > Replying to [comment:265 nullius]:
 > > I presume you refer to #24351.  As its reporter, I should emphasize
 that on one point you are correct:  I do not suggest that Tor or Tor
 Browser should “block all of Cloudflare”.  Rather, on the application
 level, Tor Browser should provide to users an informed choice—with sane
 defaults, appropriate to the level of the Security Slider.
 > >
 > > On High Security, I would expect that Cloudflare be blocked by default
 (with option to override); at Low Security, I would expect that it be
 permitted by default; in the middle, I am still on the fence.  Moreover,
 at all security levels, ''the lock icon must stop lying to users''.  The
 mixed-content warning on the lock icon provides a good precedent for how
 to proceed here, plus an existing UI graphic for consistency.
 > >
 > > A big part of the problem with Cloudflare is that it’s both invisible
 and pervasive.  Do ''you'' know how much of your own `https` web traffic
 passes in plaintext through Cloudflare’s hands?  Do you even have any
 reasonable means of measuring this?  Most of all, do you have any means of
 avoiding Cloudflare—short of avoiding the Web altogether?
 >
 > You don't seem to be familiar with how the Security Slider choices come
 from. Here's a sample ticket to get the gist of it: #23409 and
 
https://trac.torproject.org/projects/tor/attachment/ticket/23409/vuln_hist_esr52
 >
 > Here's the point: '''You can't come up with something similar for
 Cloudflare''', and so the "tie Cloudflare-thing to the security slider" is
 doomed to fail ''ab initio''.

 Read the title of this ticket. Sure you can't tie Cloudflare-thing to the
 security slider but you can tie "corporate MITM" to the security slider.

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

Re: [tor-bugs] #24862 [Metrics/Consensus Health]: Add per-relay tor versions to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay tor versions to the consensus health detailed page
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:1 tom]:
 > So "Only In Consensus" is for when the relay does not appear in the vote
 at all then?  Makes sense.

 Oops, yes!
 Or also when the relay is in the vote, but its version is not in the vote.

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

Re: [tor-bugs] #24853 [Core Tor/Tor]: backport the new authority and fallback file formats (was: backport the new authority and fallback files)

[Tor Bug Tracker & Wiki]

#24853: backport the new authority and fallback file formats
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, 025-backport- |  Actual Points:
  maybe, 029-backport, 030-backport-maybe,   |
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The new fallback file is backported, but I want to keep the same entires,
 and change the format (again, sorry).
 Using a similar format for authority and fallback files should make it
 easier for the same tool to parse 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

[tor-bugs] #24863 [Core Tor/Tor]: Travis CI environment change breaks clang builds

[Tor Bug Tracker & Wiki]

#24863: Travis CI environment change breaks clang builds
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-ci
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It looks like an unannounced environment change in Travis CI's workers
 prevents LeakSanitizer from working correctly, breaking our Travis builds
 on clang.  This seems to disable ptrace capabilities, which for some
 reason LeakSanitizer needs to run properly on our forking tests.  (See
 https://github.com/travis-ci/travis-ci/issues/9033).

 We can hope they fix this soon, or we can try to work around it by
 changing our `.travis.yml` to use a sudo-enabled build environment.  (This
 has the drawback that some of our tests depend on running as non-root, but
 I think they all get skipped if running as 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] #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:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by justmeee):

 disk drive from is ST2000LX 001-1RG174 SCSI

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by justmeee):

 Intel Core i5-6200 cpu @ 2.3 GHz, Installed RAM 12 GB
 firefox memory use shows approx 2.5 GB
 tor memory shows approx 35 MB

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:5 karsten]:
 > Replying to [comment:4 teor]:
 > > There are a few tickets that want this feature, #24834 is one of them.
 > > We would really like this feature so we can map bwauth bias.
 >
 > Understood. However, this feature is still unrealistic to implement
 without doing major code changes first. Earlier today I parsed votes for
 something unrelated (delay between relays announcing a new version and
 authorities including that in their vote), and I was once more surprised
 how big votes are compared to other descriptors. We simply cannot handle
 this data in Onionoo right now. Sorry!

 Do you need more developer time, more disk, more CPU, or more RAM?
 Because we can try to make these things happen.

 (Another alternative for #24834 is that we build a quick stem script to
 export the data we need, and import it into Relay Search.)

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

Re: [tor-bugs] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Reminder than Comment:16, posted by cypherpunks, was edited by
 "cypherpunks" to remove speech.
 It used to read:

 Tor is a honeypot for peedos and snitches.
 Tor is used to drone niggers.

 I will add to this list:
 Tor is a gommunist tool of control.
 From the time-sync, to the interface, to the controller, it has been
 designed to regulate how people access the internet and share information.

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

Re: [tor-bugs] #24573 [Core Tor/Tor]: rewrite_node_address_for_bridge() should set IPv6 preferences even if there is no ri

[Tor Bug Tracker & Wiki]

#24573: rewrite_node_address_for_bridge()  should set IPv6 preferences even if
there is no ri
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-bridge-client, easy,   |  Actual Points:
  intro, review-group-28 |
Parent ID:  #20916   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 Yes, the updated version is fine. Let's get it merged.

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

Re: [tor-bugs] #24421 [Applications/Tor Browser]: "Temporarily allow all this page" and uploads get inherited when New Identity is chosen.

[Tor Bug Tracker & Wiki]

#24421: "Temporarily allow all this page" and uploads get inherited when New
Identity is chosen.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-newnym, TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:11 gk]:
 > mcs, brade do you have some cycles to look at this bug? I probably
 won't, alas. :(

 Kathy and I spent some time debugging this today, but we did not find the
 root cause. Due to other committments, we may not have much time to work
 on this until next week, so I am posting what we learned so far here:
 * Running with e10s disabled (MOZ_FORCE_DISABLE_E10S=1) avoids the
 problem.
 * I am not convinced it is the cause of this bug because NoScript appears
 to catch the errors and ignore them, but when running with a debug build
 when e10s is enabled, several messages like the following are emitted
 right after the call to `nsSvc.eraseTemp()` (called from Torbutton's
 torbutton_do_new_identity() function):
 {{{
 [Child 23233] ###!!! ASSERTION: ENSURE_MAIN_PROCESS failed. Cannot
 SetCharPref from content process: temp: 'Error', file /.../dev/tor/tor-
 browser/modules/libpref/nsPrefBranch.cpp, line 195
 }}}
 * I don't know anything about the NoScript internals, but when this bug
 occurs it seems that `eraseTemp()` (inside NoScript's Main.js) is called
 twice: once directly by Torbutton and once in response to a `browser
 :purge-session-history` observer notification. But I don't know if the
 fact that `eraseTemp()` is called twice is causing a problem.

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

Re: [tor-bugs] #24862 [Metrics/Consensus Health]: Add per-relay tor versions to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay tor versions to the consensus health detailed page
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 So "Only In Consensus" is for when the relay does not appear in the vote
 at all then?  Makes sense.

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:265 nullius]:
 > I presume you refer to #24351.  As its reporter, I should emphasize that
 on one point you are correct:  I do not suggest that Tor or Tor Browser
 should “block all of Cloudflare”.  Rather, on the application level, Tor
 Browser should provide to users an informed choice—with sane defaults,
 appropriate to the level of the Security Slider.
 >
 > On High Security, I would expect that Cloudflare be blocked by default
 (with option to override); at Low Security, I would expect that it be
 permitted by default; in the middle, I am still on the fence.  Moreover,
 at all security levels, ''the lock icon must stop lying to users''.  The
 mixed-content warning on the lock icon provides a good precedent for how
 to proceed here, plus an existing UI graphic for consistency.
 >
 > A big part of the problem with Cloudflare is that it’s both invisible
 and pervasive.  Do ''you'' know how much of your own `https` web traffic
 passes in plaintext through Cloudflare’s hands?  Do you even have any
 reasonable means of measuring this?  Most of all, do you have any means of
 avoiding Cloudflare—short of avoiding the Web altogether?

 You don't seem to be familiar with how the Security Slider choices come
 from. Here's a sample ticket to get the gist of it: #23409 and
 
https://trac.torproject.org/projects/tor/attachment/ticket/23409/vuln_hist_esr52

 Here's the point: '''You can't come up with something similar for
 Cloudflare''', and so the "tie Cloudflare-thing to the security slider" is
 doomed to fail ''ab initio''.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24862 [Metrics/Consensus Health]: Add per-relay tor versions to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay tor versions to the consensus health detailed page
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 There seems to be a bug where directory authorities take a while to update
 relays' Tor versions:
 https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html

 In the Overlap table, let's mark versions as "In Vote And Consensus" if
 the vote matches the consensus, "Only In Vote" if the version is present
 and does not match the consensus, and "Only In Consensus" if the version
 does not match the consensus.

 Unfortunately, consensus-health does not load descriptors, so we can't
 check the actual version reported by the relay.

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

Re: [tor-bugs] #17224 [Core Tor/Tor]: Refactor common parts of parse_dir_authority_line and parse_dir_fallback_line

[Tor Bug Tracker & Wiki]

#17224: Refactor common parts of parse_dir_authority_line and
parse_dir_fallback_line
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, refactor   |  Actual Points:
  technical-debt |
Parent ID:  #24818   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  lorax, easy, tor-client, refactor technical-debt => easy, tor-
 client, refactor technical-debt
 * points:  small/medium => 0.5
 * parent:   => #24818
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


Comment:

 #24818 is a good opportunity to do this.

 We should also update the man page to document the existing constraints:
 * fallback fields can appear in any order
 * authority flags can appear in any order, but the rest of the fields must
 appear in that order
 * bridge authorities require a nickname, otherwise you end up with an
 authority called "bridge"

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

Re: [tor-bugs] #24861 [Core Tor/Tor]: Using %zu seems to break mingw :/

[Tor Bug Tracker & Wiki]

#24861: Using %zu seems to break mingw :/
+--
 Reporter:  nickm   |  Owner:  ffmancera
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  mingw compatibility regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 That's probably 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

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Oh!  Actually, fragile-hardening does make some code extremely slow, and
 the sha3 code might be one such code.  Do you get the same result without
 it?

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
--+
 Reporter:  tyng  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.8-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 My guess is that this relay has both IPv4 ans IPv6 connections to some of
 its peers. Options include A) checking for that and not logging in that
 case. B) Marking one of these duplicate connections as non-canonical, so
 the duplicates won't persist.

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

Re: [tor-bugs] #24861 [Core Tor/Tor]: Using %zu seems to break mingw :/

[Tor Bug Tracker & Wiki]

#24861: Using %zu seems to break mingw :/
+--
 Reporter:  nickm   |  Owner:  ffmancera
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  mingw compatibility regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by catalyst):

 We might want to avoid using `PRIuSZ` or anything too similar because
 macros of that shape are reserved in C99's "Future library directions" for
 inttypes.h.  Maybe `TOR_PRIuSZ`?  Or is that too long?

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

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Okay, here we are:
 {{{
 Jan 10 20:20:31.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
 labeled as LZMA compressed, and it seems to be LZMA compressed.
 Jan 10 20:20:31.000 [debug] dir_client_decompress_response_body():
 Successfully decompressed body using LZMA compressed
 Jan 10 20:20:31.000 [debug] consensus_diff_apply(): About to apply
 consensus diff.
 Jan 10 20:20:31.000 [debug] consensus_diff_apply(): Computed digest-as-
 signed for applying consensus diff.
 Jan 10 20:20:48.000 [debug] consdiff_apply_diff(): Extracted digests for
 consensus diff.
 Jan 10 20:20:48.000 [debug] consdiff_apply_diff(): Digests match; applying
 diff.
 Jan 10 20:20:48.000 [debug] consdiff_apply_diff(): Diff applied.
 Jan 10 20:20:48.000 [debug] consdiff_apply_diff(): Computing digest of
 resulting consensus.
 Jan 10 20:20:48.000 [debug] consdiff_apply_diff(): Digests are equal; diff
 application succeeded.
 Jan 10 20:20:48.000 [info] handle_response_fetch_consensus(): Applied
 consensus diff (size 235301) from server 'XX.XX.XX.XX:9001', resulting in
 a new consensus document (size 1897672).
 }}}
 I compile tor with `--enable-fragile-hardening` but it seems to me that
 does not explain the 17 seconds for extracting digests for consensus diff.
 But I might be 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] #24774 [Core Tor/Tor]: Edit prop279 to support alternative name representations and non-English languages

[Tor Bug Tracker & Wiki]

#24774: Edit prop279 to support alternative name representations and non-English
languages
+--
 Reporter:  nullius |  Owner:  (none)
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop279, review-group-28, tor-spec  |  Actual Points:
Parent ID:  #10747  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nullius):

 Replying to [comment:5 nickm]:

 Thanks for the guidance, @nickm.

 If you want for me to split out different patches, then when time permits
 (not now), I could edit everything into atomic commits in different
 branches and push it up somewhere under https://github.com/nym-zone .
 That would be less burdensome for me than trying to keep track of and
 upload multiple patch files.  Per `doc/HACKING/GettingStarted.md`, would
 that work best for you also?

 In response to some of the points you raised:

 > +1 on using RFC3492 if we want unicode support.

 I am strongly against making this an absolute requirement.  The SOCKS v5
 protocol can pass any arbitrary octets, even names with embedded `'\0'`s.
 We probably want to forbid those and other control characters; but if a
 SOCKS request hands Tor a name which won’t garble the Name System API
 protocol, then Tor should be pass that on to the Name System API resolver
 as an opaque blob.

 Of course, ''currently existing'' applications will give Tor non-ASCII
 names in Punycode.  Still, I urge that permitting this would help future-
 proof the spec for use with non-DNS-like names.  Punycode is only a
 (horribly designed) backward compatibility layer to meet the needs of a
 vast installed base of DNS software which the Tor Name System API will
 never need to deal with.

 Whereas as a potential implementer, I must say, Punycode decoding is a
 thing I’d prefer to avoid in security-sensitive code.  A search of the CVE
 database tends to support me here.

 > I am unconvinced that we need a * wildcard; the motivating examples
 seems like something that could just as well be done within a separate
 domain.

 At least as from me, the idea is to permit address encodings which don’t
 even look like RFC1034 Internet domains.  I presented two different use
 cases on `tor-dev`.  There certainly must be other many use cases I
 haven’t thought of.

 > I'm not sure that the sandboxing section is necessary. We should say
 that _all_ plugins should only access the network over Tor, unless they
 are using some comparably strong anonymity mechanism. And for filesystem
 access, if we _do_ allow * wildcards, there's no reason to suppose that
 they don't need caching as much as anything else.

 My own use cases need neither network nor filesystem access; but I will
 try to edit my proposed change to allow for those which do, without being
 overly permissive in some way which may compromise security.

 The proposal as written states under §3.2, specifically discussing `'*'`:

 > Perhaps we trust the name plugin itself, but maybe the name system
 network could exploit this?

 What does this mean?  Is there any specific information on what potential
 exploits the spec authors have thought of?  '''Would requiring Tor-only
 connections prevent these potential exploits?'''  I should ask on `tor-
 dev`.

 

 As a general point:  When designing a new spec for such a feature as the
 Name System API, I suggest that it’s important to not limit unforeseen
 potential use cases.  Don’t even try to guess what future innovations will
 look like, other than thinking like an attacker and trying to break
 things.  As long as security is not compromised, the spec should be as
 flexible as it reasonably can be.

 This reminds me of a design philosophy I just yesterday saw well-expressed
 by [https://lists.linuxfoundation.org/pipermail/bitcoin-
 dev/2018-January/015537.html Mark Friedenbach in a totally unrelated
 discussion]:

 > Finally, even if we had perfect foresight into how a feature will be
 used, which we don't, it is still the case that we would want to enable
 permission-less innovation with the generic construct...  [It] is the
 opinion of this author that new [] features should follow the UNIX
 philosophy as expressed by Peter Salus and Mike Gancarz and paraphrased by
 yours truly:
 >
 >  * Write features that do one thing and do it well.
 >  * Write features to work together.
 >  * Simple is beautiful.

 “Permission-less innovation” means that if someone invents a .

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 I'll make the discussed two changes and a few more and will have something
 for you to review some time tomorrow!

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

Re: [tor-bugs] #24812 [Webpages/Website]: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists only two

[Tor Bug Tracker & Wiki]

#24812: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists 
only
two
--+--
 Reporter:  cypherpunks   |  Owner:  kat5
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

 * status:  assigned => needs_review


Comment:

 Ready for review/merge:
 https://gitweb.torproject.org/user/kat/webwml.git/log/?h=tshirt-fix-num-
 ways

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

Re: [tor-bugs] #24812 [Webpages/Website]: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists only two

[Tor Bug Tracker & Wiki]

#24812: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists 
only
two
--+--
 Reporter:  cypherpunks   |  Owner:  kat5
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

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


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

Re: [tor-bugs] #24853 [Core Tor/Tor]: backport the new authority and fallback files

[Tor Bug Tracker & Wiki]

#24853: backport the new authority and fallback files
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-auth, 025-backport- |  Actual Points:
  maybe, 029-backport, 030-backport-maybe,   |
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I think that the fallback file is already backported?

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

Re: [tor-bugs] #24148 [Community/Outreach]: Start a program where developers can call out volunteers for swag and glory

[Tor Bug Tracker & Wiki]

#24148: Start a program where developers can call out volunteers for swag and 
glory
+
 Reporter:  arma|  Owner:  alison
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by kat5):

 If it's easier for Jon if I collect shirt prefs, shipping address, etc and
 add it to a spreadsheet (the way we do relay shirts) I'm happy to do that.

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

Re: [tor-bugs] #24861 [Core Tor/Tor]: Using %zu seems to break mingw :/

[Tor Bug Tracker & Wiki]

#24861: Using %zu seems to break mingw :/
+--
 Reporter:  nickm   |  Owner:  ffmancera
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  mingw compatibility regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by ffmancera):

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


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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nullius):

 Replying to [comment:263 cypherpunks]:
 > While I disagree with their proposal, I think  the proposal isn't "block
 all of Cloudflare", but rather "mark as insecure traffic whose HTTP
 headers indicate that it has been tempered by Cloudflare, i.e. it has for
 e.g. `CF-RAY:"3db104efec5c14cd-CDG"` in its HTTP headers" (you can test
 that with https://discordapp.com/)

 I presume you refer to #24351.  As its reporter, I should emphasize that
 on one point you are correct:  I do not suggest that Tor or Tor Browser
 should “block all of Cloudflare”.  Rather, on the application level, Tor
 Browser should provide to users an informed choice—with sane defaults,
 appropriate to the level of the Security Slider.

 On High Security, I would expect that Cloudflare be blocked by default
 (with option to override); at Low Security, I would expect that it be
 permitted by default; in the middle, I am still on the fence.  Moreover,
 at all security levels, ''the lock icon must stop lying to users''.  The
 mixed-content warning on the lock icon provides a good precedent for how
 to proceed here, plus an existing UI graphic for consistency.

 A big part of the problem with Cloudflare is that it’s both invisible and
 pervasive.  Do ''you'' know how much of your own `https` web traffic
 passes in plaintext through Cloudflare’s hands?  Do you even have any
 reasonable means of measuring this?  Most of all, do you have any means of
 avoiding Cloudflare—short of avoiding the Web altogether?

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nullius):

 Replying to [comment:260 cypherpunks]:
 > This long, long, long ticket finally got a response from Tor
 project member.
 >
 > https://lists.torproject.org/pipermail/tor-dev/2018-January/012779.html

 I replied on-list, with mention of this bug and discussion of #24351:
 https://lists.torproject.org/pipermail/tor-dev/2018-January/012787.html

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

[tor-bugs] #24861 [Core Tor/Tor]: Using %zu seems to break mingw :/

[Tor Bug Tracker & Wiki]

#24861: Using %zu seems to break mingw :/
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  mingw compatibility regression
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It looks like we found out why we weren't using `%zu` before:
 {{{
 17:55:39 In file included from src/or/or.h:72:0,
 17:55:39  from src/or/circuitlist.c:54:
 17:55:39 src/or/circuitlist.c: In function 'circuits_handle_oom':
 17:55:39 src/or/circuitlist.c:2407:26: error: unknown conversion type
 character 'z' in format [-Werror=format=]
 17:55:39log_notice(LD_GENERAL, "We're low on memory (cell queues total
 alloc: %zu,"
 17:55:39   ^
 17:55:39 ./src/common/torlog.h:232:45: note: in definition of macro
 'log_notice'
 17:55:39log_fn_(LOG_NOTICE, domain, __FUNCTION__, args, ##__VA_ARGS__)
 17:55:39  ^~~~
 17:55:39 src/or/circuitlist.c:2407:26: error: unknown conversion type
 character 'z' in format [-Werror=format=]
 17:55:39log_notice(LD_GENERAL, "We're low on memory (cell queues total
 alloc: %zu,"
 17:55:39   ^
 }}}
 (from https://jenkins.torproject.org/job/tor-ci-mingwcross-
 master/1577/ARCHITECTURE=amd64,SUITE=stretch/consoleFull)

 In theory we can select a more c99 one with `__USE_MINGW_ANSI_STDIO`, but
 that would change our stdio everywhere. (Which is a little scary.)

 We could also define a PRIsz macro that has the correct format for
 whatever compiler we are using.  That might be a better choice.

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

Re: [tor-bugs] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Replying to [comment:5 dcf]:
 > Replying to [comment:4 yawning]:
 > > Replying to [comment:2 dcf]:
 > > > I was pretty surprised by this, because I was under the impression
 that tor always sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` nowadays, and
 therefore this code should never have worked in any released bundle. But
 it turns out it only sets the variable for server transports, not client
 transports, which is why this bug wasn't detected earlier:
 > >
 > > I don't remember why it only does that on servers.  Should it set the
 env var for clients as well?
 >
 > I had assumed that it was set for clients too. I can't think of a reason
 why it wouldn't be (except for this bug, of course).

 I certainly intended for it to be everywhere when I added the construct,
 and obfs4proxy checks the env var regardless of if it is a client or
 server.  I looked back at my commit, and the code's unchanged from when I
 added the patch, so I guess it's a bug that's always been there.

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

Re: [tor-bugs] #23894 [Webpages]: remove help desk email from bridges.torproject.org

[Tor Bug Tracker & Wiki]

#23894: remove help desk email from bridges.torproject.org
--+
 Reporter:  alison|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by alison):

 Three months later and the wrong address is still there!

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

Re: [tor-bugs] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

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


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

Re: [tor-bugs] #24733 [Core Tor/Tor]: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOS

[Tor Bug Tracker & Wiki]

#24733: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour 
on
x86_64 macOS
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  address-sanitizer, unexpected-   |  Actual Points:  0.1
  consequences, review-group-28  |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

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


Comment:

 Thanks! Squashed and merging.

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

Re: [tor-bugs] #24774 [Core Tor/Tor]: Edit prop279 to support alternative name representations and non-English languages

[Tor Bug Tracker & Wiki]

#24774: Edit prop279 to support alternative name representations and non-English
languages
+--
 Reporter:  nullius |  Owner:  (none)
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop279, review-group-28, tor-spec  |  Actual Points:
Parent ID:  #10747  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 +1 on using RFC3492 if we want unicode support.

 As for the other changes:
   * I like the idea of explicitly saying "This address is definitively
 non-mapped; no other plugin should be allowed to map it.
   * I am unconvinced that we need a * wildcard; the motivating examples
 seems like something that could just as well be done within a separate
 domain.
   * I'm not sure that the sandboxing section is necessary.  We should say
 that _all_ plugins should only access the network over Tor, unless they
 are using some comparably strong anonymity mechanism.  And for filesystem
 access, if we _do_ allow * wildcards, there's no reason to suppose that
 they don't need caching as much as anything else.

 I think that having separate patches for the different issues here might
 make them easier to discuss.

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

Re: [tor-bugs] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 Replying to [comment:4 yawning]:
 > Replying to [comment:2 dcf]:
 > > I was pretty surprised by this, because I was under the impression
 that tor always sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` nowadays, and
 therefore this code should never have worked in any released bundle. But
 it turns out it only sets the variable for server transports, not client
 transports, which is why this bug wasn't detected earlier:
 >
 > I don't remember why it only does that on servers.  Should it set the
 env var for clients as well?

 I had assumed that it was set for clients too. I can't think of a reason
 why it wouldn't be (except for this bug, of course).

 The purpose of the [[comment:21:ticket:15435|terminateprocess-buffer]]
 program, which we [https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/projects/tor-browser/Bundle-Data/PTConfigs/windows/torrc-
 defaults-appendix?id=66f424078b1971d393406165f79d050e78d574f2#n8 still
 use] on Windows, was to simulate support for `TOR_PT_EXIT_ON_STDIN_CLOSE`
 in tor clients that don't have it. In my reasoning three years ago I
 thought that `TOR_PT_EXIT_ON_STDIN_CLOSE` was coming for clients and that
 terminateprocess-buffer would not be necessary someday.

 But that brings up another question: terminateprocess-buffer
 [https://gitweb.torproject.org/pluggable-transports/meek.git/tree
 /terminateprocess-buffer/terminateprocess-buffer.go?h=0.28#n30 sets]
 `TOR_PT_EXIT_ON_STDIN_CLOSE=1` unconditionally (and also provides its
 child process with a stdin). So it seems that this bug should have arisen
 on Windows, with meek-client exiting immediately because it doesn't have a
 stdin.

 The documentation for `exec.Cmd` [https://golang.org/pkg/os/exec/#Cmd
 says]:
   If Stdin is nil, the process reads from the null device (os.DevNull).
 Where [https://golang.org/pkg/os/#pkg-constants os.DevNull] is NUL on
 Windows. So all I can think of is that NUL doesn't provide an immediate
 EOF like /dev/null does. Or maybe I am missing something else. I need to
 run some more 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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nullius):

 Bug reporter here.

 Replying to [comment:56 akrey]:
 > Cloudflare is not a man in the middle. Cloudflare is authorized to
 provide the SSL termination for origin, by origin.

 The short version, a rhetorical question:  Would you trust a key escrow
 régime, in which an “authorized” entity was entrusted with the
 ''potential'' to decrypt ''all'' communications at will?  If not, why
 would you trust a ''de facto'' mass decryption chokepoint at which
 ''many'' communications are ''actually'' decrypted?  Apropos this ticket,
 by analogy, would you trust a web browser which displayed a lock icon
 promising the confidentiality, integrity, and authentication of key-
 escrowed communications?

 The longer version:

 As I’ve said elsewhere, Cloudflare is ''sui generis''.  There is not even
 one other entity on Earth today who has realtime “authorized” decrypt
 access to the scope and nature of traffic which passes through Cloudflare.
 Billions of connections to millions of different websites!

 The mass-surveillance potential should be obvious.  Officially,
 [https://www.cloudflare.com/transparency/ Cloudflare does respond to
 government inquiries], as they are required to by U.S. law; this is no
 different from any other U.S. entity, except for the ''huge'' difference
 in the scope of data which Cloudflare has available to it.  Unofficially,
 they could do anything they want with the data they glean from mass-
 decryption; and this imposes the requirement of trust on what’s supposed
 to be a protocol which is built on the adage, “trust the algorithms”.

 Also, you are looking at this question from the wrong perspective.  Tor
 Browser does not exist for the purpose of permitting whatever may be
 “authorized” by origins; indeed, as referenced below, Tor Browser takes
 extensive measures to deliberately ''break'' many things “authorized” by
 origins.  Tor Browser’s job is to protect the user’s privacy, not to serve
 websites.  As such, Tor Browser should protect users against having a
 large proportion of their HTTPS Web use silently, invisibly decrypted by a
 single centralized entity.

 Really, it’s a matter of user choice and the ''user’s'' authorization.  I
 think I have made it clear in my prior comments, I do not wish to prevent
 users from accessing Cloudflared sites.  Rather, the lock icon should stop
 lying to users—and users should be given an informed choice of whether
 they wish to permit Cloudflare to read their traffic, with appropriate
 default settings for different Security Slider levels.  Just as users can
 also override certificate verification and accept the self-signed
 certificate of a MITM running sslstrip, I urge the motto, “Mechanism, not
 policy.”

 And yes, by definition, Cloudflare ''are'' a man in the middle:  They
 silently decrypt, read/modify, and re-encrypt the TLS connection between
 two endpoints.  Be that not a MITM, then what is?  I put this as a
 secondary point, because quibbling over definitions gets nowhere; the
 substance of this bug is in the nature of what Cloudflare does.

 Now, the remainder of your arguments seem to posit that given many
 problems, the multiplicity of problems is reason to do nothing about the
 biggest one:

 > Do you say that tbb should block sites because their internal setup is
 insecure (and yes, cloudflare ''is'' part of that 'internal setup')?

 Please name even one other other singular “internal setup” which, whether
 compromised or not, has full access to the traffic of billions of visitors
 to millions of different websites.

 > Should tbb also block sites that run on rented cloud machinery, because
 they are inherently insecure, and subvertible by the hosting companies?

 Please name even one “cloud” provider which hosts a comparable breadth,
 depth, and apparent diversity of sites to those which have their traffic
 decrypted by Cloudflare.

 > Should tbb also block google-analytics, for obvious reasons?

 Are you trying to add to my wishlist?

 Seriously, Tor Browser already puts considerable effort into prevention of
 third

Re: [tor-bugs] #24501 [Core Tor/Tor]: When we hit MaxMemInQueues, make the log message more quantitative

[Tor Bug Tracker & Wiki]

#24501: When we hit MaxMemInQueues, make the log message more quantitative
-+
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-28  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 ok, looks solid. merging to 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] #7590 [Core Tor/Tor]: [PATCH] New option LocalOutboundBindAddress

[Tor Bug Tracker & Wiki]

#7590: [PATCH] New option LocalOutboundBindAddress
-+-
 Reporter:  ac   |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-hs, hs-integration,  |  Actual Points:
  hs-app-support, review-group-28|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Review:
   * The `conn_get_outbound_address` function should have its documentation
 updated to explain what the new argument does, and how the function
 behaves now.
   * There should be tests for this, and a changes file.

 Otherwise this looks great to me!

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 It looks like the merge request on oniongit is back up! Please let me know
 if you'd like me to copy my comments from here there, or from there here.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by manish.earth):

 > Does CString::new() do a complete copy on the message?

 It depends what you give it. If you give it borrowed data, it will copy.
 If you give it a String or a Vec, it will copy.

 (I'll have a look at the code soon, missed that it was updated)

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

Re: [tor-bugs] #23975 [Core Tor/Tor]: Make node_get_pref_ipv6_orport() check addresses in the right order

[Tor Bug Tracker & Wiki]

#23975: Make node_get_pref_ipv6_orport() check addresses in the right order
---+
 Reporter:  teor   |  Owner:  teor
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  ipv6, review-group-28  |  Actual Points:  2
Parent ID:  #20916 | Points:  1
 Reviewer:  nickm  |Sponsor:  SponsorV-can
---+
Changes (by nickm):

 * status:  needs_review => needs_revision
 * reviewer:   => nickm


Comment:

 Looks plausible!  It's good to see so much complexity removed here.

 I think we already merged #23736, so I'll assume we rebase before the
 merge to drop 189127acf2014907eac747e25d32668741dc2c5e ?

 Let's add a comment to document SET_IPV6_AP.  We should ''especially''
 document that it conditionally returns, possibly by renaming it: macros
 that alter control flow should make it obvious.

 Other than that, I think I like this.  How is the test coverage for all
 the functions in policies.c that we modify?

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

Re: [tor-bugs] #24733 [Core Tor/Tor]: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOS

[Tor Bug Tracker & Wiki]

#24733: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour 
on
x86_64 macOS
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  address-sanitizer, unexpected-   |  Actual Points:  0.1
  consequences, review-group-28  |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Thanks, looks good to me!

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

Re: [tor-bugs] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Replying to [comment:2 dcf]:
 > I was pretty surprised by this, because I was under the impression that
 tor always sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` nowadays, and therefore
 this code should never have worked in any released bundle. But it turns
 out it only sets the variable for server transports, not client
 transports, which is why this bug wasn't detected earlier:
 >
 
https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=9e8b762fcecfece64aae70ae640aaa59fd227ca5#n1387

 I don't remember why it only does that on servers.  Should it set the env
 var for clients as well?

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

Re: [tor-bugs] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mcs):

 Replying to [comment:2 dcf]:
 > You're right. This is a bug in meek-client-torbrowser.
 >
 > Better than unsetting `TOR_PT_EXIT_ON_STDIN_CLOSE`, I think, is to
 actually give the meek-client subprocess a stdin, something like this:
 > ...
 > Another (possibly better) option is to call `cmd.StdinPipe()` and just
 never close the pipe (that way the child process's stdin is separate from
 the parent's, so you don't have a race between them trying to terminate
 when the stdin is closed).

 The above makes sense to me. `cmd.StdinPipe()` seems like a good solution.
 Kathy and I can test such a patch if you'd like us to do so.

 > ...
 > What do you need from me, a new tag with this bug fixed?

 Yes.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 I've added a series of fixup commits to my `bug24526` branch to try to fix
 the issues matched above.  Shall I squash and commit?

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  needs_revision => accepted


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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:58 karsten]:
 > ...
 > > You only need to look at the latest four commits.  The others are
 reviewed already (comment:47).
 >
 > Oh. That information would have saved some time this morning. That also
 explains why I have just one remark on the earlier commits and a couple
 more on the first four!

 Hrmm, in my request for review I did mention:

... The additional commits should address all topics from the comments
 above starting at comment:47. ...

 Maybe, too subtle for 'please re-read the comments starting at comment:47
 unless you memorized them earlier' ;-)

 >
 > ...
 > There are two types of changes here:
 >
 >  1. Changes in the review process that require knowing the branch under
 review. Ideally, we'd use "fixup" or "squash" commits for all commits made
 during the review process. Alternatively, we can agree that commits will
 be squashed prior to merge, which works for me, too.
 >  2. Changes in the merge process that only require knowing master before
 the merge. Somebody who didn't follow the review process, including our
 future selfs, should see changes where we're not going forth and back
 throughout commit series to achieve something that we could do in one
 step.

 Sounds ok.

 >
 >  ...
 > Anyway, here's what I found in your branch:
 >
 >  - `AccessLogLineSanVal` contains an explicit mention of `"FTP"`. Does
 this mean we're considering FTP log lines to be valid? Why FTP in
 particular and no other protocols? Or should we take that out and restrict
 ourselves to HTTP? Not feeling strongly about this one.

 Please also refer to comments 50 to 52.  The main issue was to not only
 declare lines as valid that resemble sanitized lines, but be more general.
 Thus, allowing different protocols could be part of that, but I don't
 insist.
 Which log lines should be considered valid?  How much can log lines differ
 from sanitized log lines and still be considered valid?  The current code
 only sketches one possibility, e.g. allowing different protocols, various
 ip addresses, and other request types.  Before making any more code
 changes there should be at least a list of valid and invalid lines or a
 description of either state.

 >  - Further down below we're comparing `referenceDate` to `extractedDate`
 and discarding lines where the two don't match. Not sure if this is
 problematic, but I'm at least flagging it here as potential issue. If this
 is a non-issue, feel free to ignore this comment.

 The variable `extractedDate` refers to the date extracted from the log
 line and reference date is the log files date (see
 [https://metrics.torproject.org/web-server-logs.html#n-re-assembling-log-
 files spec section 4.3]).  As discarding is only performed during
 sanitization this is ok.  The lines would be considered valid.

 >  - A few lines further down we're formatting a date using
 `DateTimeFormatter.ofPattern()`. Is that expensive? Would we be able to
 create the formatter just once and re-use it here? Not trying to optimize
 prematurely, but trying to avoid shooting ourselves in the foot.

 Makes sense. (1)

 >  - Logging an error in case of catching a `Throwable` might become very
 noisy. After all, we're processing third-party input here, and we can
 typically proceed without parsing that line. The debug level seemed like
 the better choice here.

 Oh, that's an oversight. (2)

 >  - In `WebServerAccessLog`, what exactly is the log date? Is it the date
 of contained requests, is it the date when the file was written to disk,
 or what is it? This is still unclear in the docs.

 [https://gitweb.torproject.org/user/iwakeh/metrics-
 
lib.git/tree/src/main/java/org/torproject/descriptor/WebServerAccessLog.java?h=task-22983-4&id=5dbbeb0ac38728f09718c80e295e8524d92d2e68#n19
 Javadoc] says:
 `Returns the date of the log as LocalDate.`
 and the [https://metrics.torproject.org/web-server-logs.html#n-re-
 assembling-log-files spec 4.3] says: `Rewritten log lines are re-assembled
 into sanitized log files based on physical host, virtual host, and request
 start date.`

 Where would a clarification be needed?

 >
 > When these remaining issues are clearer to me, do you mind me editing
 your branch and preparing one or more "fixup"/"squash" commits? There are
 still a few things that I'd like to document differently or where I'd lik

Re: [tor-bugs] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 Works for me. I just updated Tor Metrics which now shows some entries as
 "$date to present".

 I guess that concludes this ticket. Feel free to keep it open if there's
 more to do, but don't keep it open for me if you think everything's done.
 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

[tor-bugs] #24860 [Core Tor/Tor]: Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c

[Tor Bug Tracker & Wiki]

#24860: Bug: Assertion cmux failed in circuitmux_get_policy at 
src/or/circuitmux.c
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-relay, tor-sched, cmux, tor-
 Severity:  Normal   |  channel
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This was triggered during an heavy load on my relay for which all the RAM
 and disk space has been consumed:

 {{{
 Dec 15 20:44:20.612 [err] tor_assertion_failed_(): Bug:
 src/or/circuitmux.c:630: circuitmux_get_policy: Assertion cmux failed;
 aborting. (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: Assertion cmux failed in
 circuitmux_get_policy at src/or/circuitmux.c:630. Stack trace: (on Tor
 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(log_backtrace+0x42) [0x55cac920c342] (on Tor
 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(tor_assertion_failed_+0x8d) [0x55cac922768d]
 (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(circuitmux_get_policy+0x57) [0x55cac9167d57]
 (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb7f41)
 [0x55cac913ff41] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(smartlist_pqueue_pop+0x156) [0x55cac9217196]
 (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb9d7e)
 [0x55cac9141d7e] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb805f)
 [0x55cac914005f] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f38ac2544c9] (on Tor
 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(do_main_loop+0x24f) [0x55cac90db53f] (on Tor
 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(tor_run_main+0x265) [0x55cac90dc9c5] (on Tor
 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug:
 /home/relay/tor/src/or/tor(tor_main+0x3a) [0x55cac90d621a] (on Tor 0.3.3.0
 -alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(main+0x19)
 [0x55cac90d5f89] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf0) [0x7f38aaf6d830] (on Tor 0.3.3.0
 -alpha-dev b1682551a6860a2b)
 Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(_start+0x29)
 [0x55cac90d5fd9] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
 }}}

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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

[tor-bugs] #24859 [Core Tor/Tor]: Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/consdiffmgr.c

[Tor Bug Tracker & Wiki]

#24859: Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at
src/or/consdiffmgr.c
--+-
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-relay, consdiff
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 During an heavy DoS on my relay, it ran out of RAM and disk space which I
 believe might have triggered this assert:

 {{{
 Dec 16 17:37:47.562 [warn] Error writing to "/home/tor/diff-cache/1224":
 Disk quota exceeded
 Dec 16 17:37:47.562 [warn] tor_bug_occurred_(): Bug:
 src/or/consdiffmgr.c:1316: store_multiple: Non-fatal assertion !(ent ==
 NULL) failed. (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: Non-fatal assertion !(ent == NULL) failed
 in store_multiple at src/or/consdiffmgr.c:1316. Stack trace: (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(log_backtrace+0x42) [0x55994d4a8382] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x55994d4c3619] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(+0x11a0c2)
 [0x55994d43e0c2] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(+0x11a7de)
 [0x55994d43e7de] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(replyqueue_process+0x51) [0x55994d4ca3c1] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f800d7404c9] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(do_main_loop+0x24f) [0x55994d37726f] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(tor_run_main+0x265) [0x55994d3786f5] (on Tor
 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug:
 /root/git/tor/src/or/tor(tor_main+0x3a) [0x55994d371f4a] (on Tor 0.3.3.0
 -alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(main+0x19)
 [0x55994d371cb9] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf0) [0x7f800c65f830] (on Tor 0.3.3.0
 -alpha-dev 424572ee0a161428)
 Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(_start+0x29)
 [0x55994d371d09] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
 }}}

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Newbie questions from oniongit that I can remember:
   * Does CString::new() do a complete copy on the message?
   * What part of the Rust code removes the indentation on the log strings?

 Change requests I can remember from oniongit:
   * The `tor_log_msg!()` macro documentation should document its support
 for `format!` syntax.
   * In C, all identifiers that start with an underscore are reserved: we
 can create constants like `LOG_WARN_`, but using `_LOG_WARN` is risky and
 we try not to do that.

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 While I disagree with their proposal, I think  the proposal isn't "block
 all of Cloudflare", but rather "mark as insecure traffic whose HTTP
 headers indicate that it has been tempered by Cloudflare, i.e. it has for
 e.g. `CF-RAY:"3db104efec5c14cd-CDG"` in its HTTP headers" (you can test
 that with https://discordapp.com/)

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 I added some comments to the merge request, but then apparently
 oniongit.eu decided to start giving me 500 errors.

 Here are the other questionsissues that I didn't enter into oniongit -- I
 hope that it comes back up again soon, and we can find the other
 questions/issues too.

 1) I'd recommend a rename on `rust_welcome_string()` to
 `rust_log_welcome_string()`: by convention, a function whose primary
 purpose is to _do_ something should have a verb name.

 2) Will the translate_* functions get inlined and compiled down to
 constants?  Logging is pretty critical-path.

 3) The C log functions exit fast, without formatting the message, if the
 log message isn't "interesting" because its severity is too low.  I think
 that if possible the Rust log macro should do the same, and avoid
 formatting messages when the function `log_message_is_interesting()`
 returns false.  That could be a separate commit, 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

Re: [tor-bugs] #24850 [Core Tor/Tor]: tor2web option without the corresponding tag in torrc causes tor to fail with confusing console output

[Tor Bug Tracker & Wiki]

#24850: tor2web option without the corresponding tag in torrc causes tor to fail
with confusing console output
-+--
 Reporter:  yurivict271  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  tor-logging, tor-config  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

 * keywords:   => tor-logging, tor-config
 * status:  reopened => new
 * milestone:   => Tor: unspecified


Comment:

 Oh the console... Hmmm, I think this is a whole new ballgame to print a
 meaningful message on the console also. I guess any critical options that
 fail could also print on the console before quitting.

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

Re: [tor-bugs] #24733 [Core Tor/Tor]: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOS

[Tor Bug Tracker & Wiki]

#24733: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour 
on
x86_64 macOS
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  address-sanitizer, unexpected-   |  Actual Points:  0.1
  consequences, review-group-28  |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * reviewer:   => catalyst


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

Re: [tor-bugs] #24850 [Core Tor/Tor]: tor2web option without the corresponding tag in torrc causes tor to fail with confusing console output

[Tor Bug Tracker & Wiki]

#24850: tor2web option without the corresponding tag in torrc causes tor to fail
with confusing console output
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yurivict271):

 * status:  closed => reopened
 * 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] #24850 [Core Tor/Tor]: tor2web option without the corresponding tag in torrc causes tor to fail with confusing console output

[Tor Bug Tracker & Wiki]

#24850: tor2web option without the corresponding tag in torrc causes tor to fail
with confusing console output
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yurivict271):

 It is clear how to make it start.

 The problem is about the lack of the console error message explaining why
 it didn't start.

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Could link against jemalloc or something and use it's introspection
 capabilities.

 http://jemalloc.net/jemalloc.3.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] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 Replying to [comment:4 teor]:
 > There are a few tickets that want this feature, #24834 is one of them.
 > We would really like this feature so we can map bwauth bias.

 Understood. However, this feature is still unrealistic to implement
 without doing major code changes first. Earlier today I parsed votes for
 something unrelated (delay between relays announcing a new version and
 authorities including that in their vote), and I was once more surprised
 how big votes are compared to other descriptors. We simply cannot handle
 this data in Onionoo right now. Sorry!

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

Re: [tor-bugs] #24738 [Core Tor/Tor]: Abort trap: 6 after installation Mac OS 10.13.1

[Tor Bug Tracker & Wiki]

#24738: Abort trap: 6 after installation Mac OS 10.13.1
-+---
 Reporter:  lL__ |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Very High|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor, error, abort, trap  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by dgoulet):

 * component:  Core Tor => Core Tor/Tor


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

Re: [tor-bugs] #24774 [Core Tor/Tor]: Edit prop279 to support alternative name representations and non-English languages

[Tor Bug Tracker & Wiki]

#24774: Edit prop279 to support alternative name representations and non-English
languages
+--
 Reporter:  nullius |  Owner:  (none)
 Type:  enhancement | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop279, review-group-28, tor-spec  |  Actual Points:
Parent ID:  #10747  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * keywords:  prop279, review-group-28 => prop279, review-group-28, tor-spec
 * component:  Core Tor => Core Tor/Tor


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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * milestone:   => Tor: unspecified


Comment:

 Datapoint: I'm running a relay right now that keeps track of most the big
 memory chunk Tor uses including descriptors. I hope to learn something but
 so far I'm also on the side of memory frag :S.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 I'd be fine with the change in log level and/or domain macros.  Reviewing
 the branch now...

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

Re: [tor-bugs] #24260 [Metrics/Website]: Add metrics timeline events underneath graphs

[Tor Bug Tracker & Wiki]

#24260: Add metrics timeline events underneath graphs
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  ux-team metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

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


Comment:

 Replying to [comment:21 iwakeh]:
 > Looks fine, both the code and the resulting news page!

 Great! Merged to master and deployed. Also created #24858 for the
 remaining next steps that we're not going to do as part of this ticket
 anymore. Closing. Thanks, everyone!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24858 [Metrics/Website]: Further tweak metrics timeline events underneath graphs and on news page

[Tor Bug Tracker & Wiki]

#24858: Further tweak metrics timeline events underneath graphs and on news page
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 In #24260 we added metrics timeline events underneath graphs and tweaked
 those on the news page. While discussing those changes we came up with a
 couple of improvements that we were unable to implement, because we didn't
 have the time. Here's the list, in case we find more time for this later
 on. We should probably create child tickets when starting on one these
 items.

  - Add tooltips to tags explaining them a little more, like "Onion-Routing
 protocol" for "".
  - Make tags clickable by linking them to a page with all events related
 to that tag.
  - Maybe make column headers clickable and as a result sort entries
 accordingly.
  - Maybe change the filtering to only show entries for all countries or
 all transports on graphs showing users from all countries or using all
 transports.
  - Add annotations to the graph or even mouseovers.
  - Add optional JavaScript magic that only displays the first entries and
 that lets the user expend the list if there are more.
  - Find categories or standards for link texts for a more consistent
 presentation.
  - Extend events to graphs in other categories than Users and then add
 this table there.

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

Re: [tor-bugs] #24850 [Core Tor/Tor]: tor2web option without the corresponding tag in torrc causes tor to fail with confusing console output

[Tor Bug Tracker & Wiki]

#24850: tor2web option without the corresponding tag in torrc causes tor to fail
with confusing console output
--+--
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


Comment:

 Set `Tor2webMode 1` in your torrc file. If not, tor won't start if
 compiled with tor2web. Once you do so, if you still have the issue, reopen
 this bug and if you can attach some info logs `Log info ...` option.

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
--+
 Reporter:  tyng  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.8-rc
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * 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] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
--+---
 Reporter:  Eugene646 |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  cpu, windows  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dgoulet):

 * status:  new => needs_information
 * keywords:  cpu => cpu, windows
 * component:  Core Tor => Core Tor/Tor


Comment:

 Are you able to see some sort of time period pattern where tor would take
 all the CPU? Like is it every hour? or every 10 minutes?

 Was it only at startup or it keeps doing it often?

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

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 (That is to say, I did not see the bug happening in either case.)

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

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 With that patch on master, I see:
 {{{
 Jan 10 10:17:51.000 [debug] HTTP body from server '154.35.175.225:443' was
 label
 ed as LZMA compressed, and it seems to be LZMA compressed.
 Jan 10 10:17:51.000 [debug] dir_client_decompress_response_body():
 Successfully
 decompressed body using LZMA compressed
 Jan 10 10:17:51.000 [debug] consensus_diff_apply(): About to apply
 consensus dif
 f.
 Jan 10 10:17:51.000 [debug] consensus_diff_apply(): Computed digest-as-
 signed fo
 r applying consensus diff.
 Jan 10 10:17:51.000 [debug] consdiff_apply_diff(): Extracted digests for
 consens
 us diff.
 Jan 10 10:17:51.000 [debug] consdiff_apply_diff(): Digests match; applying
 diff.
 Jan 10 10:17:51.000 [debug] consdiff_apply_diff(): Diff applied.
 Jan 10 10:17:51.000 [debug] consdiff_apply_diff(): Computing digest of
 resulting
  consensus.
 Jan 10 10:17:51.000 [debug] consdiff_apply_diff(): Digests are equal; diff
 appli
 cation succeeded.
 Jan 10 10:17:51.000 [info] handle_response_fetch_consensus(): Applied
 consensus
 diff (size 101910) from server '154.35.175.225:443', resulting in a new
 consensu
 s document (size 1884843).
 }}}

 I wonder what could be going wrong here.

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

Re: [tor-bugs] #24793 [Obfuscation/Obfsproxy]: obfs4 breaks http proxy with basic auth

[Tor Bug Tracker & Wiki]

#24793: obfs4 breaks http proxy with basic auth
---+
 Reporter:  gilcu3 |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/commit/?id=af4824cb0b2c36a0eba4bc1590eb0737302e992e

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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:57 iwakeh]:
 > Replying to [comment:56 karsten]:
 > > I started looking at your branch, but it's a pretty big diff again, so
 that'll take some time.
 >
 > You only need to look at the latest four commits.  The others are
 reviewed already (comment:47).

 Oh. That information would have saved some time this morning. That also
 explains why I have just one remark on the earlier commits and a couple
 more on the first four!

 > > Regarding Git history, we're going to squash all these commits (except
 for unrelated ones like adding a space or package-info) into a single
 commit that adds interfaces, implementations, and tests, right? I'm
 asking, because you marked some commits as "fixup!", but not all of them.
 Or do you have a separation in mind? If so, which?
 > >
 >
 > Maybe, keep those that you find easier to understand the changes.  I
 used 'fixup' for making clear that a change is related to an earlier
 review discussion.

 There are two types of changes here:

  1. Changes in the review process that require knowing the branch under
 review. Ideally, we'd use "fixup" or "squash" commits for all commits made
 during the review process. Alternatively, we can agree that commits will
 be squashed prior to merge, which works for me, too.
  2. Changes in the merge process that only require knowing master before
 the merge. Somebody who didn't follow the review process, including our
 future selfs, should see changes where we're not going forth and back
 throughout commit series to achieve something that we could do in one
 step.

 > > By the way, what was the reason for rebasing your branch? It would
 have been a tad bit easier to stay on the same branch until we're done
 with the review process. Just saying for future reviews.
 >
 > You mentioned that above already ;-)
 > (I think, last year I did the rebase because it seemed better to work on
 a branch close to master.)

 Maybe I ran into that rebase today when fetching from your repository and
 seeing this branch to be force-updated. But it's good to know I mentioned
 this before. With a few more samples you'll soon be able to compute my
 attention span. :)

 Anyway, here's what I found in your branch:

  - `AccessLogLineSanVal` contains an explicit mention of `"FTP"`. Does
 this mean we're considering FTP log lines to be valid? Why FTP in
 particular and no other protocols? Or should we take that out and restrict
 ourselves to HTTP? Not feeling strongly about this one.
  - Further down below we're comparing `referenceDate` to `extractedDate`
 and discarding lines where the two don't match. Not sure if this is
 problematic, but I'm at least flagging it here as potential issue. If this
 is a non-issue, feel free to ignore this comment.
  - A few lines further down we're formatting a date using
 `DateTimeFormatter.ofPattern()`. Is that expensive? Would we be able to
 create the formatter just once and re-use it here? Not trying to optimize
 prematurely, but trying to avoid shooting ourselves in the foot.
  - Logging an error in case of catching a `Throwable` might become very
 noisy. After all, we're processing third-party input here, and we can
 typically proceed without parsing that line. The debug level seemed like
 the better choice here.
  - In `WebServerAccessLog`, what exactly is the log date? Is it the date
 of contained requests, is it the date when the file was written to disk,
 or what is it? This is still unclear in the docs.

 When these remaining issues are clearer to me, do you mind me editing your
 branch and preparing one or more "fixup"/"squash" commits? There are still
 a few things that I'd like to document differently or where I'd like to
 make the new code more similar to existing code (in the good sense). You
 could still go through them and talk me out of making those changes. Sound
 okay?

 Oh, and here's another remark for future reviews: let's try to reduce the
 time for reviewing and for revising a branch to a few days. Neither
 reviewing nor revising is fun, but it's even less fun when doing it
 several weeks later. I know this is a special case with the holiday break,
 and I'm not blaming you any more than I'm blaming myself. Just an idea to
 make reviews a little more fun. :)

--
Ticket URL: 

[tor-bugs] #24857 [Core Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
---+--
 Reporter:  Eugene646  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:  Tor: 0.3.1.9
 Severity:  Normal |   Keywords:  cpu
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Hi,

 I have tor 0.3.1.9 running as non-exit relay.
 From time to time it starts consuming 100% of CPU. Even though network
 traffic is minimal.
 Is it normal? If not, how can I help you to investigate it?

 My system is Win 7 x64 SP1, cpu is Core i5-3570.

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

Re: [tor-bugs] #24733 [Core Tor/Tor]: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOS

[Tor Bug Tracker & Wiki]

#24733: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour 
on
x86_64 macOS
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  address-sanitizer, unexpected-   |  Actual Points:  0.1
  consequences, review-group-28  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've tried to make the requested changes in branch `bug24733`.  Okay to
 merge it?

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

Re: [tor-bugs] #24573 [Core Tor/Tor]: rewrite_node_address_for_bridge() should set IPv6 preferences even if there is no ri

[Tor Bug Tracker & Wiki]

#24573: rewrite_node_address_for_bridge()  should set IPv6 preferences even if
there is no ri
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-bridge-client, easy,   |  Actual Points:
  intro, review-group-28 |
Parent ID:  #20916   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-

Comment (by nickm):

 teor, can you confirm that you like this version of the patch?

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

Re: [tor-bugs] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

[Tor Bug Tracker & Wiki]

#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  easy, refactor, review-group-28  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merging!

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