Re: [tor-bugs] #27535 [Applications/Tor Browser]: TLS 1.3 is disabled in Tor Browser

2018-09-14 Thread Tor Bug Tracker & Wiki
#27535: TLS 1.3 is disabled in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-8.0.1-can,   |  Actual Points:
  GeorgKoppen201809, TorBrowserTeam201809R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by watt):

 Draft 23 and 0rtt by default?!
 Feature that was manually disabled up to Fx60 (but shipped since Fx52) is
 offered now to Tor Browser's users to become beta-testers or what?!

 Replying to [comment:6 watt]:
 > Replying to [comment:2 gk]:
 > > I think there is no reason to differ from Firefox here.
 > Sure?
 https://bugzilla.mozilla.org/show_bug.cgi?id=1462099

 Fuck! Tor Browser is not a toy (for some users, at least)!

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

Re: [tor-bugs] #27158 [Community/Translations]: Add browserOnboarding.properties to Transifex

2018-09-14 Thread Tor Bug Tracker & Wiki
#27158: Add browserOnboarding.properties to Transifex
+--
 Reporter:  gk  |  Owner:  emmapeel
 Type:  task| Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

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


Comment:

 Ok this is 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

[tor-bugs] #27718 [Internal Services/Service - git]: Add translations repo to the attic

2018-09-14 Thread Tor Bug Tracker & Wiki
#27718: Add translations repo to the attic
-+
 Reporter:  emmapeel |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 The translations repo holds one branch per project:
 https://gitweb.torproject.org/translation.git/

 But some branches are not used anymore.

 I would like to be able to move them to the attic, so they don't clutter
 the view. I don't want to delete them permanently, because they are, after
 all, our translation memory.

 Can I have a translations-attic repo where I push all those branches, and
 then I can delete them from translation.git ?

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

2018-09-14 Thread Tor Bug Tracker & Wiki
#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 Replying to [comment:18 ma1]:
 > I think you're wrong, indeed. The message handler gets enabled only
 after initialization is completed.
 Yep, I saw that. I conflated evidence of the message with evidence of the
 handling.
 > That approach is reliable, except on the very first load of a local
 (bypassing webRequest) page. I.e. if you set a file:, data: or about: URL
 as your home page (or, regrettably, if you're using session restore and
 that's the last active tab) NoScript won't be able to affect it on first
 load.
 Thanks for the explanation. This seems reasonable to me (but probably it
 should be documented).
 > A work-around would be detecting some in the static content scripts
 (which appear to run anyway) that the dynamic content scripts didn't (i.e.
 NoScript's background script has not been initialized yet), stopping the
 load and triggering a (delayed?) reload. Maybe this could be helped by
 waiting for a response to a dummy HTTP fetch() request, relying on the web
 traffic deferral, in order to prevent reload loops in case something
 fails.
 I don't understand it well, but it seems convoluted. Porbably webext
 should grow explicit API to cover these cases.

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

Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

2018-09-14 Thread Tor Bug Tracker & Wiki
#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201809   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 So after some investigation today, I've figured out where we can insert
 the call that initializes the whitelisted directory paths such that they
 are all initialized correctly:

 Updated patch: https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_26381_v2=10=0=0

 I've also reopened the Mozilla bug since their proposed solution is a non-
 starter, due to the blocking nature of the tor configuration window and
 the updater's dependency on tor to work properly.

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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

2018-09-14 Thread Tor Bug Tracker & Wiki
#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 Replying to [comment:66 cypherpunks3]:
 > Can I get a tl;dr as to what this patch does?
 When RFP is on, http header is spoofed according to a 2-tuple (windows on
 pc, and android on mobile). Entry in javascript navigator object is
 spoofed according to the 4-tuple described in the bugzilla ticket above
 (android, linux, mac, windows).
 (That's now another way to pick out tor browser from firefox)

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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

2018-09-14 Thread Tor Bug Tracker & Wiki
#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 Replying to [comment:65 gk]:
 > Replying to [comment:64 mcs]:
 > > Replying to [comment:63 gk]:
 > > > Looks mostly good to me. I guess we could refactor
 `Navigator::GetUserAgent()` a bit but we can leave that our for now and
 tackle that when upstreaming this patch.
 > >
 > > Kathy and I were a little afraid to make big changes there without
 advice from a Mozilla person and/or more time to test things.
 >
 > Yes, I guessed so and that's been a good idea.
 >
 > >
 > > > Please adjust the WinXP in the commit message and the title given
 that you delete `general.useragent.override` from the prefs we ship but
 have the bug fixed nevertheless. Maybe "Bug 26146: Spoof HTTP User-Agent
 header for desktop platforms"? (or something like that). Oh, and that's
 not only JavaScript on/off related. The risk we are writing the patch for
 is that the OS is collected by any server Tor Browser is talking to,
 irrespective of your JS settings.
 > >
 > > Here is a revised patch (new commit message):
 > > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug26146-02=a9b83ea79e2e1751d63fffe62b457008d516145e
 >
 > Looks good! I cherry-picked the patch to `tor-browser-60.2.0esr-8.5-1`
 (commit 165031359d2db55af85cab32713860bb6a026483) and `tor-
 browser-60.2.0esr-8.0-1` (commit
 62d76b2381c1df0b893336f496ae4ffe161d592f). Woo, thanks everyone!

 Can I get a tl;dr as to what this patch does?

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

Re: [tor-bugs] #27676 [Applications/Tor Browser]: On Linux the Tor Browser .desktop launcher sets wrong path for icon

2018-09-14 Thread Tor Bug Tracker & Wiki
#27676: On Linux the Tor Browser .desktop launcher sets wrong path for icon
--+---
 Reporter:  yaomtc|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yaomtc):

 Oops, sorry, forgot to search first. 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] #27717 [Core Tor/Stem]: Report tor segfaults when integ testing

2018-09-14 Thread Tor Bug Tracker & Wiki
#27717: Report tor segfaults when integ testing
---+--
 Reporter:  atagar |  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  testing easy
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 From time to time Stem's integration tests crash tor (for example,
 #27500). When this happens our test output is pretty confusing since from
 the point of the crash onward we fail with generic 'cannot connect to tor'
 errors.

 There's two issues here...

 1. Our test output doesn't indicate that tor crashed.

 2. When reporting tor segfaults we need its stacktrace, which is swallowed
 by our tests.

 We should adjust our test's get_tor_controller() helper to check if tor is
 still alive, failing the test with a clearer message if it isn't and
 providing the tor stacktrace at the end of the test run.

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

Re: [tor-bugs] #27273 [Core Tor/Tor]: ASan fails to link on Travis due to rustc and linker arguments

2018-09-14 Thread Tor Bug Tracker & Wiki
#27273: ASan fails to link on Travis due to rustc and linker arguments
--+
 Reporter:  alexcrichton  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:  #25386| Points:
 Reviewer:|Sponsor:
--+

Comment (by alexcrichton):

 Sure yeah, I've opened https://github.com/rust-lang/rust/issues/54237 for
 that.

 Thinking about this again though, it may be the case that `-nodefaultlibs`
 is a red herring in the sense that the link errors may just be fixable by
 linking the libraries that otherwise wouldn't be linked. I'd have to dig
 more into the precise linker errors though which I sort of forget at this
 point :(

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

2018-09-14 Thread Tor Bug Tracker & Wiki
#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorQ
-+-

Comment (by mikeperry):

 0.3.3 and 0.3.4 don't leak with this branch:
 https://github.com/torproject/tor/pull/342

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

2018-09-14 Thread Tor Bug Tracker & Wiki
#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorQ
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok, new rebased+squashed PR against 0.2.9:
 https://github.com/torproject/tor/pull/340

 I decided to make a branch against 0.3.2 also, because our relay metrics
 still show 1/3 of our relays still using it:
 https://metrics.torproject.org/versions.html

 Merge to 0.3.2 required a test fix to mock assert_circuit_ok. New PR:
 https://github.com/torproject/tor/pull/341

 0.3.3 and 0.3.4 have memory leaks in the tests due to unrelated circuitmux
 changes. Chasing those down.

 If we like this, I will fix up 0.3.3 and 0.3.4, and do the merge commit 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

[tor-bugs] #27716 [Metrics/CollecTor]: Out of memory when loading in multiple years of relay descriptors

2018-09-14 Thread Tor Bug Tracker & Wiki
#27716: Out of memory when loading in multiple years of relay descriptors
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 The interesting thing here is that this happens **after** the descriptors
 have been imported and written into the `out/` and `recent/` directories.
 This implies that we're not that far off being able to handle huge imports
 of relay descriptors.

 I believe this is happening in the `ReferenceChecker` but I haven't
 confirmed this.

 {{{
 2018-09-14 17:26:42,757 INFO o.t.m.c.c.Scheduler:150 New Thread created:
 CollecTor-Scheduled-Thread-1
 2018-09-14 17:26:42,758 INFO o.t.m.c.c.CollecTorMain:66 Starting
 relaydescs module of CollecTor.
 2018-09-14 17:26:42,762 INFO o.t.d.DescriptorSourceFactory:150 Serving
 implementation org.torproject.descriptor.impl.DescriptorParserImpl for
 descriptor.parser.
 2018-09-14 18:32:21,639 INFO o.t.m.c.r.ArchiveReader:273 Finished
 importing relay descriptors from local directory:
 Parsed 5253040, ignored 0 files.
 2018-09-14 18:32:21,759 INFO o.t.m.c.r.ArchiveWriter:484 Finished writing
 relay descriptors to disk.
 While importing relay descriptors from local directory, we stored 0
 consensus(es), 0 microdesc consensus(es), 0 vote(s), 0 certificate(s),
 5253040 server descriptor(s), 0 extra-info descriptor(s), and 0
 microdescriptor(s) to disk.
 Statistics on the completeness of written relay descriptors:
 2018-09-14 18:32:21,760 WARN o.t.m.c.r.ArchiveWriter:535 The last known
 relay server descriptor was published at 2018-09-13 19:32:29, which is
 more than 5:30 hours in the past.
 2018-09-14 18:32:21,760 WARN o.t.m.c.r.ArchiveWriter:542 The last known
 relay extra-info descriptor was published at 2018-09-13 19:32:29, which is
 more than 5:30 hours in the past.
 2018-09-14 18:32:21,761 WARN o.t.m.c.r.ArchiveWriter:549 The last known
 relay microdescriptor was contained in a microdesc consensus that was
 valid after 2018-09-13 14:00:00, which is more than 5:30 hours in the
 past.
 2018-09-14 18:32:22,528 INFO o.t.d.DescriptorSourceFactory:150 Serving
 implementation org.torproject.descriptor.impl.DescriptorReaderImpl for
 descriptor.reader.
 2018-09-14 18:32:22,558 ERROR o.t.d.i.DescriptorReaderImpl:165 Bug:
 uncaught exception or error while reading descriptors: Required array size
 too large
 java.lang.OutOfMemoryError: Required array size too large
 at java.nio.file.Files.readAllBytes(Files.java:3156)
 at
 
org.torproject.descriptor.impl.DescriptorReaderImpl$DescriptorReaderRunnable.readDescriptorFile(DescriptorReaderImpl.java:333)
 at
 
org.torproject.descriptor.impl.DescriptorReaderImpl$DescriptorReaderRunnable.readDescriptorFiles(DescriptorReaderImpl.java:255)
 at
 
org.torproject.descriptor.impl.DescriptorReaderImpl$DescriptorReaderRunnable.run(DescriptorReaderImpl.java:161)
 at java.lang.Thread.run(Thread.java:748)
 2018-09-14 18:32:22,559 ERROR o.t.m.c.c.CollecTorMain:71 The relaydescs
 module failed: Saving history is only permitted after reading descriptors.
 java.lang.IllegalStateException: Saving history is only permitted after
 reading descriptors.
 at
 
org.torproject.descriptor.impl.DescriptorReaderImpl.saveHistoryFile(DescriptorReaderImpl.java:116)
 at
 
org.torproject.metrics.collector.relaydescs.ReferenceChecker.readNewDescriptors(ReferenceChecker.java:201)
 at
 
org.torproject.metrics.collector.relaydescs.ReferenceChecker.check(ReferenceChecker.java:89)
 at
 
org.torproject.metrics.collector.relaydescs.ArchiveWriter.startProcessing(ArchiveWriter.java:194)
 at
 org.torproject.metrics.collector.cron.CollecTorMain.run(CollecTorMain.java:67)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
 2018-09-14 18:32:22,561 INFO o.t.m.c.c.ShutdownHook:23 

Re: [tor-bugs] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ

2018-09-14 Thread Tor Bug Tracker & Wiki
#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
-+-
 Reporter:  nusenu   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, fast-fix, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Discussion with armadev on IRC. Snippet of good questions we must answer:

 {{{
 <+armadev> how many relays would we lose right now if we set this new
 minimums
 <+armadev> and, if we keep the Fast flag away from the new bottom 1/8,
 will there be quite fast relays who still don't get the Fast flag?
 ...
 <+armadev> historically we said a higher number in the man page than we
 actually enforced in the code
 ...
 <+armadev> kicking out relays by quietly changing a number is something we
 should think hard about
 <+armadev> maybe we raise the code minimum some,
 <+armadev> and also warn if it's below 1MB
 <+armadev> saying that in the future it'll be higher
 <+armadev> i could get behind a code-enforced 256KB
 }}}

 Useful notes ^ that I agree with!

 I'm putting this one in needs_revision so we can properly address this.
 Nick mentioned he would be fine to do that 035 post-freeze.

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

Re: [tor-bugs] #27010 [UX/Research]: UX Research

2018-09-14 Thread Tor Bug Tracker & Wiki
#27010: UX Research
-+--
 Reporter:  antonela |  Owner:  nyinz
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor9
-+--
Changes (by brade):

 * cc: mcs, brade (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] #25090 [Applications/Tor Browser]: Make sure IPFS & co in addons are shoved up through Tor and don't leak in ESR60

2018-09-14 Thread Tor Bug Tracker & Wiki
#25090: Make sure IPFS & co in addons are shoved up through Tor and don't leak 
in
ESR60
+
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  ff60-esr, tbb-proxy-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 I think we are good right now. There is no TCP/UDP Socket API available
 for WebExtensions yet (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1247628) so, this risk is
 ruled out. You can register those protocols with protocol handlers (see:
 https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/manifest.json/protocol_handlers) but that's a web based
 mechanism, so that should be fine.

 That said: even if extensions which implemented/supported those protocols
 *would* bypass Tor then I think this would fall under our strong
 recommendation to not install third-party extensions as they can
 compromise your privacy/anonymity.

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

Re: [tor-bugs] #27613 [Webpages/Support]: Tor Browser manual link appear in Danish in Tails

2018-09-14 Thread Tor Bug Tracker & Wiki
#27613: Tor Browser manual link appear in Danish in Tails
-+-
 Reporter:  arthuredelstein  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages/Support |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-8.0-issues,|  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by emmapeel):

 I think it would be great if:
 - When user ends up in  to https://support.torproject.org/zh-
 TW/tbb/tbb-25/ which gives 404
 - Gets forwarded to https://support.torproject.org/tbb/tbb-25/  instead.

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

Re: [tor-bugs] #27714 [Metrics/ExoneraTor]: support more recent lookups

2018-09-14 Thread Tor Bug Tracker & Wiki
#27714: support more recent lookups
+--
 Reporter:  exonerator  |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by exonerator):

 (if that is not possible or is causing to much work, it would be nice to
 have the limitation shown on the page before the user runs into the error
 that the timestamp is to recent "Date parameter too recent")

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27715 [Metrics/ExoneraTor]: support relative time in timestamp parameter

2018-09-14 Thread Tor Bug Tracker & Wiki
#27715: support relative time in timestamp parameter
+--
 Reporter:  exonerator  |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 for our tor exit abuse ticket system (which is sending auto-replies) it
 would be nice to be able to include a direct exonerator URL with our IP
 and say a lookup for yesterday (or 2 days ago)

 The auto-reply text is static so the URL would also have to be a static
 string

 http://metrics.torproject.org/exonerator.html?ip=1.1.1.1=-1=en

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

Re: [tor-bugs] #13005 [Webpages/Website]: Please document Tor Browser environment variables

2018-09-14 Thread Tor Bug Tracker & Wiki
#13005: Please document Tor Browser environment variables
--+--
 Reporter:  mttp  |  Owner:  traumschule
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  faq   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/webwml/pull/49

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27714 [Metrics/ExoneraTor]: support more recent lookups

2018-09-14 Thread Tor Bug Tracker & Wiki
#27714: support more recent lookups
+--
 Reporter:  exonerator  |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 exonerator currently requires the date to be older than 2 days, could this
 be reduced to 24 hours?

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

Re: [tor-bugs] #27697 [Metrics/ExoneraTor]: Release ExoneraTor 4.0.0

2018-09-14 Thread Tor Bug Tracker & Wiki
#27697: Release ExoneraTor 4.0.0
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  task| Status:  closed
 Priority:  High|  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

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


Comment:

 Announced: https://lists.torproject.org/pipermail/tor-
 relays/2018-September/016209.html

 Closing. Thanks!

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

Re: [tor-bugs] #27712 [Core Tor/Tor]: Introduce Finite State Machine abstraction into Tor codebase

2018-09-14 Thread Tor Bug Tracker & Wiki
#27712: Introduce Finite State Machine abstraction into Tor codebase
--+-
 Reporter:  rl1987|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: very long term
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  idea lorax|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by rl1987):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27713 [Core Tor/Tor]: uncrustify config file to autofix C code whitespace and indentation

2018-09-14 Thread Tor Bug Tracker & Wiki
#27713: uncrustify config file to autofix C code whitespace and indentation
--+--
 Reporter:  rl1987|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 See: https://github.com/uncrustify/uncrustify

 Making it correspond to things that `make check-spaces` checks for would
 be convenient for C developer working with 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

[tor-bugs] #27712 [Core Tor/Tor]: Introduce Finite State Machine abstraction into Tor codebase

2018-09-14 Thread Tor Bug Tracker & Wiki
#27712: Introduce Finite State Machine abstraction into Tor codebase
--+-
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: very long term
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  idea lorax
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This would make e.g. our SOCKS code easier to understand and maintain.

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

Re: [tor-bugs] #27710 [Community/Relays]: How often do relays upload their descriptor per day?

2018-09-14 Thread Tor Bug Tracker & Wiki
#27710: How often do relays upload their descriptor per day?
--+
 Reporter:  traumschule   |  Owner:  Nusenu
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by irl):

 It is probably not important to add this to the relay guide.

 It is covered in dir-spec:

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n344

 There are more cases though than are covered in dir-spec. This could
 potentially be a ticket to update dir-spec with all possible cases in
 which a relay would upload a new descriptor.

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

Re: [tor-bugs] #17488 [Metrics/ExoneraTor]: ExoneraTor hangs forever on old known-positive test

2018-09-14 Thread Tor Bug Tracker & Wiki
#17488: ExoneraTor hangs forever on old known-positive test
+--
 Reporter:  starlight   |  Owner:  metrics-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  metrics-2018|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

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


Comment:

 This is finally resolved by #27356 and released in version 4.0.0. Closing.

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

Re: [tor-bugs] #27356 [Metrics/ExoneraTor]: Reduce database size and variance of query response times

2018-09-14 Thread Tor Bug Tracker & Wiki
#27356: Reduce database size and variance of query response times
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  closed
 Priority:  High|  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

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


Comment:

 Released. Closing. Thanks, Sebastian and irl!

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

Re: [tor-bugs] #27677 [Core Tor/Tor]: document minimum required python versions

2018-09-14 Thread Tor Bug Tracker & Wiki
#27677: document minimum required python versions
--+--
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/tor/pull/339

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

Re: [tor-bugs] #27675 [Core Tor/Tor]: test_rebind.py depends on python >=2.7 or >=3.1

2018-09-14 Thread Tor Bug Tracker & Wiki
#27675: test_rebind.py depends on python >=2.7 or >=3.1
--+
 Reporter:  catalyst  |  Owner:  rl1987
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by rl1987):

 * status:  accepted => needs_review


Comment:

 https://github.com/torproject/tor/pull/338

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

Re: [tor-bugs] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

2018-09-14 Thread Tor Bug Tracker & Wiki
#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  neel
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, 035-roadmap- |  Actual Points:
  proposed, tbb-needs|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => merge_ready
 * reviewer:   => dgoulet


Comment:

 I believe this is now accurate! Thanks neel!

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

Re: [tor-bugs] #27711 [Core Tor/Tor]: Hardened build fails in tortls_openssl.c

2018-09-14 Thread Tor Bug Tracker & Wiki
#27711: Hardened build fails in tortls_openssl.c
--+
 Reporter:  rl1987|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Fixed with af39649aade3da87ac23ad62605e2273f92d9d47

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

Re: [tor-bugs] #26806 [Core Tor/Tor]: Check if Tor clients sometimes send duplicate cells on rendezvous circuits: Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen (

2018-09-14 Thread Tor Bug Tracker & Wiki
#26806: Check if Tor clients sometimes send duplicate cells on rendezvous 
circuits:
Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section
was seen
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #27711 [Core Tor/Tor]: Hardened build fails in tortls_openssl.c

2018-09-14 Thread Tor Bug Tracker & Wiki
#27711: Hardened build fails in tortls_openssl.c
--+
 Reporter:  rl1987|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 thanks; fixing!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27711 [Core Tor/Tor]: Hardened build fails in tortls_openssl.c

2018-09-14 Thread Tor Bug Tracker & Wiki
#27711: Hardened build fails in tortls_openssl.c
--+
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 src/lib/tls/tortls_openssl.c: In function ‘tor_tls_release_socket’:
 src/lib/tls/tortls_openssl.c:1172:5: error: value computed is not used
 [-Werror=unused-value]
  BIO_set_close(rbio, BIO_NOCLOSE);
  ^
 src/lib/tls/tortls_openssl.c:1175:5: error: value computed is not used
 [-Werror=unused-value]
  BIO_set_close(wbio, BIO_NOCLOSE);
  ^
 cc1: all warnings being treated as errors
 make: *** [src/lib/tls/src_lib_libtor_tls_a-tortls_openssl.o] Error 1
 }}}

 https://travis-ci.org/torproject/tor/jobs/428655734

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

Re: [tor-bugs] #27335 [Core Tor/Tor]: Tor bug when hs directory is missing

2018-09-14 Thread Tor Bug Tracker & Wiki
#27335: Tor bug when hs directory is missing
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.6-rc
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Cherry-picked to 0.3.2; merged forward.

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

Re: [tor-bugs] #27040 [Core Tor/Tor]: [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.

2018-09-14 Thread Tor Bug Tracker & Wiki
#27040: [warn] We don't have a consensus, so we can't perform v2 rendezvous
operations.
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords:  fast-fix easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 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] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ

2018-09-14 Thread Tor Bug Tracker & Wiki
#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
-+-
 Reporter:  nusenu   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, fast-fix, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => arma


Comment:

 I'm okay with this, but I'd like arma's opinion too.

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

Re: [tor-bugs] #27709 [Core Tor/Tor]: The compiler doesn't warn about tor_assert(a = b)

2018-09-14 Thread Tor Bug Tracker & Wiki
#27709: The compiler doesn't warn about tor_assert(a = b)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 032-backport|  Actual Points:
  033-backport 034-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 (ahf says it looks okay to him, but it should get another reviewer too)

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

Re: [tor-bugs] #27289 [Core Tor/Tor]: Count raw bytes on the wire correctly when using NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27289: Count raw bytes on the wire correctly when using NSS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:  #26631| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #27289 [Core Tor/Tor]: Count raw bytes on the wire correctly when using NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27289: Count raw bytes on the wire correctly when using NSS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26631| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by nickm):

 squashed and 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] #27040 [Core Tor/Tor]: [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.

2018-09-14 Thread Tor Bug Tracker & Wiki
#27040: [warn] We don't have a consensus, so we can't perform v2 rendezvous
operations.
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  fast-fix easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * keywords:  fast-fix easy 034-backport => fast-fix easy
 * cc: dgoulet (removed)
 * status:  new => merge_ready


Comment:

 See branch: `ticket27040_035_01`.

 Trivial fix. We can't backport such a thing imo... Doesn't fall under our
 backport rules. If I'm wrong, great, put back the keyword :).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27710 [Community/Relays]: How often do relays upload their descriptor per day?

2018-09-14 Thread Tor Bug Tracker & Wiki
#27710: How often do relays upload their descriptor per day?
--+
 Reporter:  traumschule   |  Owner:  Nusenu
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This question came up in #tor-dev today and wasn't answered so far.

 [[TorRelayGuide]] should know, but it does not tell.

 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] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ

2018-09-14 Thread Tor Bug Tracker & Wiki
#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
-+-
 Reporter:  nusenu   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, fast-fix, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #26094 [Core Tor/Tor]: manpage: increase minimal bandwidth requirements to be consistent with the relay guide and FAQ

2018-09-14 Thread Tor Bug Tracker & Wiki
#26094: manpage: increase minimal bandwidth requirements to be consistent with 
the
relay guide and FAQ
-+-
 Reporter:  nusenu   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, fast-fix, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Ok wild branch. By fixing the man page, I figured we should also change
 the real requirement in the code. This will probably lead to some relays
 being unhappy and warnings ... but if we want to do this, definitely
 035 is a good one because next LTS.

 See branch: `ticket26094_035_01`

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

Re: [tor-bugs] #27709 [Core Tor/Tor]: The compiler doesn't warn about tor_assert(a = b)

2018-09-14 Thread Tor Bug Tracker & Wiki
#27709: The compiler doesn't warn about tor_assert(a = b)
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 032-backport|  Actual Points:
  033-backport 034-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => 029-backport 032-backport 033-backport 034-backport
 * status:  accepted => needs_review


Comment:

 See branch `bug27709_029`, with PR at
 https://github.com/torproject/tor/pull/337

 This is important IMO, since it has potential to suppress important
 compiler warnings.

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

Re: [tor-bugs] #27552 [Applications/Tor Browser]: Latest tor browser launcher broken on linux (CentOS 6.8)

2018-09-14 Thread Tor Bug Tracker & Wiki
#27552: Latest tor browser launcher broken on linux (CentOS 6.8)
+--
 Reporter:  LinuxProbes |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 I think we could ask Centos 6 users to install the firefox package, and in
 our wrapper script check if we are on Centos 6 and add
 `/usr/lib64/firefox/bundled/lib64` to `LD_LIBRARY_PATH` in that 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] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

2018-09-14 Thread Tor Bug Tracker & Wiki
#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, 035-roadmap- |  Actual Points:
  proposed, tbb-needs|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I now compare the flags and `rend_pk_digest` and have pushed 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] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

2018-09-14 Thread Tor Bug Tracker & Wiki
#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:64 mcs]:
 > Replying to [comment:63 gk]:
 > > Looks mostly good to me. I guess we could refactor
 `Navigator::GetUserAgent()` a bit but we can leave that our for now and
 tackle that when upstreaming this patch.
 >
 > Kathy and I were a little afraid to make big changes there without
 advice from a Mozilla person and/or more time to test things.

 Yes, I guessed so and that's been a good idea.

 >
 > > Please adjust the WinXP in the commit message and the title given that
 you delete `general.useragent.override` from the prefs we ship but have
 the bug fixed nevertheless. Maybe "Bug 26146: Spoof HTTP User-Agent header
 for desktop platforms"? (or something like that). Oh, and that's not only
 JavaScript on/off related. The risk we are writing the patch for is that
 the OS is collected by any server Tor Browser is talking to, irrespective
 of your JS settings.
 >
 > Here is a revised patch (new commit message):
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug26146-02=a9b83ea79e2e1751d63fffe62b457008d516145e

 Looks good! I cherry-picked the patch to `tor-browser-60.2.0esr-8.5-1`
 (commit 165031359d2db55af85cab32713860bb6a026483) and `tor-
 browser-60.2.0esr-8.0-1` (commit
 62d76b2381c1df0b893336f496ae4ffe161d592f). Woo, 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

Re: [tor-bugs] #27289 [Core Tor/Tor]: Count raw bytes on the wire correctly when using NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27289: Count raw bytes on the wire correctly when using NSS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26631| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #27709 [Core Tor/Tor]: The compiler doesn't warn about tor_assert(a = b)

2018-09-14 Thread Tor Bug Tracker & Wiki
#27709: The compiler doesn't warn about tor_assert(a = b)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => 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] #27446 [Core Tor/Tor]: Vague 'see log' response when HS creation fails

2018-09-14 Thread Tor Bug Tracker & Wiki
#27446: Vague 'see log' response when HS creation fails
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


Comment:

 Moving to Unspecified.

 To try to go forward, I wonder here if there is a world where we would
 want to report any configuration error on the control port instead of only
 the logs? The entire HS configuration process can go through a LOT of
 errors...

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

Re: [tor-bugs] #26556 [Applications/Tor Browser]: Tor Browser icon missing from .desktop

2018-09-14 Thread Tor Bug Tracker & Wiki
#26556: Tor Browser icon missing from .desktop
-+-
 Reporter:  jscott   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, GeorgKoppen201809,  |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Fixed on `master` (commit 5d99870ce97b06252c393c12f0c4d2bcf326d6c3) and
 `maint-8.0` (commit eb6a0da7fc417f7f0b42c99a072e18056c8c40dc), 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] #27097 [Applications/Tor Browser]: Add "Tor News" newsletter signup link in Tor Browser

2018-09-14 Thread Tor Bug Tracker & Wiki
#27097: Add "Tor News" newsletter signup link in Tor Browser
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-fundraising,|  Actual Points:
  TorBrowserTeam201809, tbb-8.0.1-can|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ux-team, tbb-fundraising, TorBrowserTeam201809R, tbb-8.0.1-can
 => ux-team, tbb-fundraising, TorBrowserTeam201809, tbb-8.0.1-can
 * status:  needs_review => needs_revision


Comment:

 Looks good! One small thing:
 {{{
 +const kAboutTorHideTorNewsBanner = this.kAboutTorHideTorNewsBanner;
 }}}
 just remove that line and use `this.kAboutTorHideTorNewsBanner` in the two
 instances needed directly. Having a `kAboutTorHideTorNewsBanner` in the
 function scope and declared above is confusing and seems not worth it.

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

Re: [tor-bugs] #26556 [Applications/Tor Browser]: Tor Browser icon missing from .desktop

2018-09-14 Thread Tor Bug Tracker & Wiki
#26556: Tor Browser icon missing from .desktop
-+-
 Reporter:  jscott   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, GeorgKoppen201809,  |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 The patch looks good to me and it seems to work.

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

2018-09-14 Thread Tor Bug Tracker & Wiki
#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorQ
-+-

Comment (by dgoulet):

 Hmmm also we might want to fix the CLANG issue pointed out by Travis:

 {{{
 src/or/rephist.c:1381:20:error:no previous extern declaration for non-
 static
   variable 'write_array' [-Werror,-Wmissing-variable-declarations]
 STATIC bw_array_t *write_array = NULL;
 }}}

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

Re: [tor-bugs] #27335 [Core Tor/Tor]: Tor bug when hs directory is missing

2018-09-14 Thread Tor Bug Tracker & Wiki
#27335: Tor bug when hs directory is missing
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.6-rc
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Branch: `bug27335_035_01`.

 Trivial fix.

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

[tor-bugs] #27709 [Core Tor/Tor]: The compiler doesn't warn about tor_assert(a = b)

2018-09-14 Thread Tor Bug Tracker & Wiki
#27709: The compiler doesn't warn about tor_assert(a = b)
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 C's assignment expressions are notoriously easy to mis-type when you are
 trying to enter an equality expression instead.  Most compilers will
 notice when you say something like `if (a = b)`, and make you add an extra
 set of parentheses.  But we've done something with our tor_assert() macro
 so this doesn't happen. We should fix that.

 Found from ahf's review of #27289

 We should also make sure BUG doesn't have this 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] #27535 [Applications/Tor Browser]: TLS 1.3 is disabled in Tor Browser

2018-09-14 Thread Tor Bug Tracker & Wiki
#27535: TLS 1.3 is disabled in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-8.0.1-can,   |  Actual Points:
  GeorgKoppen201809, TorBrowserTeam201809R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks for that. Merged to `tor-browser-60.2.0esr-8.5.-1` (commit
 dc3519d999329f06042409786568e8e871503a92) and cherry-picked to `tor-
 browser-60.2.0esr-8.0-1` (commit
 32b4b24c4cf56b9e88c7aae60c1db5affabd99b1).

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats info leak upon close of circuits with queued cells

2018-09-14 Thread Tor Bug Tracker & Wiki
#23512: Bandwidth stats info leak upon close of circuits with queued cells
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorQ
-+-
Changes (by dgoulet):

 * cc: dgoulet (removed)
 * reviewer:   => dgoulet
 * status:  needs_review => needs_revision


Comment:

 Reviewed, minor things, no show stopper, just possible simplification and
 comment upgrade ;).

 @mikeperry, there is a possible argument for this to be based on 029 ...
 and if not, we should base it on 033 since 032 is EOL in 3 weeks.

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

Re: [tor-bugs] #27708 [Core Tor/Tor]: Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5

2018-09-14 Thread Tor Bug Tracker & Wiki
#27708: Heap use-after-free on git master 
dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, crash, 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged to 0.3.3 and forward.

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

Re: [tor-bugs] #27289 [Core Tor/Tor]: Count raw bytes on the wire correctly when using NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27289: Count raw bytes on the wire correctly when using NSS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26631| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 pushed some fixup commits. Better now?

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

Re: [tor-bugs] #27469 [Applications/Tor Launcher]: Change the moat service URL

2018-09-14 Thread Tor Bug Tracker & Wiki
#27469: Change the moat service URL
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Merged to `master` (commit
 1db5a1ccddffe78c6b1ff242acfa628d9e9823e0).

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

Re: [tor-bugs] #27535 [Applications/Tor Browser]: TLS 1.3 is disabled in Tor Browser

2018-09-14 Thread Tor Bug Tracker & Wiki
#27535: TLS 1.3 is disabled in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-8.0.1-can,   |  Actual Points:
  GeorgKoppen201809, TorBrowserTeam201809R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by brade):

 r=brade, r=mcs
 looks good.

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

Re: [tor-bugs] #27708 [Core Tor/Tor]: Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5

2018-09-14 Thread Tor Bug Tracker & Wiki
#27708: Heap use-after-free on git master 
dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, crash, 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 ACK. I confirm the problem is 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] #27469 [Applications/Tor Launcher]: Change the moat service URL

2018-09-14 Thread Tor Bug Tracker & Wiki
#27469: Change the moat service URL
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by brade):

 r=brade, r=mcs
 looks good.

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

Re: [tor-bugs] #27708 [Core Tor/Tor]: Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5

2018-09-14 Thread Tor Bug Tracker & Wiki
#27708: Heap use-after-free on git master 
dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, crash, 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review
 * keywords:  regression, crash => regression, crash, 033-backport
 034-backport


Comment:

 See branch `bug27708_033`, PR at
 https://github.com/torproject/tor/pull/336

 The problem was caused by my restart-in-process changes: once we started
 returning -1 after a failed options_act(), we were leaving the
 global_options variable in an inconsistent state.

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

2018-09-14 Thread Tor Bug Tracker & Wiki
#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Replying to [comment:17 cypherpunks3]:
 > Replying to [comment:15 ma1]:
 > > It should not: NoScript defers all the HTTP(S) traffic until its
 policy is configured and ready to be enforced.
 > Ok, so let's say it only breaks in harmless cases. Regardless, it still
 looks like a bug to me: the handler for `fetchChildPolicy` is running
 before making sure the state is properly initialised; for example, the
 object `ns.policy` is used and dereferenced in `getForDocument` even
 though it could still be null. Or maybe I'm wrong, I'm just reading this
 code now.
 >

 I think you're wrong, indeed. The message handler gets enabled only after
 initialization is completed.

 > > about:blank, data: and file: URLs are those which might suffer of this
 problem, because NoScript has no means to prevent them from loading before
 it's initialized.
 > Does that mean that the approach mentioned there
 [ticket:27553#comment:3] is unreliable because of this race?

 That approach is reliable, except on the very first load of a local
 (bypassing webRequest) page. I.e. if you set a file:, data: or about: URL
 as your home page (or, regrettably, if you're using session restore and
 that's the last active tab) NoScript won't be able to affect it on first
 load.

 A work-around would be detecting some in the static content scripts (which
 appear to run anyway) that the dynamic content scripts didn't (i.e.
 NoScript's background script has not been initialized yet), stopping the
 load and triggering a (delayed?) reload. Maybe this could be helped by
 waiting for a response to a dummy HTTP fetch() request, relying on the web
 traffic deferral, in order to prevent reload loops in case something
 fails.

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

Re: [tor-bugs] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

2018-09-14 Thread Tor Bug Tracker & Wiki
#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, 035-roadmap- |  Actual Points:
  proposed, tbb-needs|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:10 neel]:
 > I have pushed these changes.

 Oh not the `dest_address` but rather the .onion address that is the
 `rend_pk_digest` that was originally removed.

 In other words, the .onion address of the SOCKS request *and* the flags
 need to be matched. Else, we'll close things that we shouldn't I think.

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

Re: [tor-bugs] #27708 [Core Tor/Tor]: Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5

2018-09-14 Thread Tor Bug Tracker & Wiki
#27708: Heap use-after-free on git master 
dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  regression, crash  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


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

Re: [tor-bugs] #27206 [Core Tor/Tor]: rust protover_all_supported() takes forever on some inputs

2018-09-14 Thread Tor Bug Tracker & Wiki
#27206: rust protover_all_supported() takes forever on some inputs
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:3 teor]:
 > So I don't think this is security-low, just slightly inefficient.

 It creates a temporary `Vec` containing up to 4 billion integers,
 actually, in order to call `.retain()` on it. The updated tests try to use
 massive amounts of RAM without this change.

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

Re: [tor-bugs] #27664 [Core Tor/Tor]: Initialization error when using NSS with Chutney

2018-09-14 Thread Tor Bug Tracker & Wiki
#27664: Initialization error when using NSS with Chutney
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  nss   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 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] #27451 [Core Tor/Tor]: Refactor socket closing in tor_tls_free() so it is not broken with NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27451: Refactor socket closing in tor_tls_free() so it is not broken with NSS
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 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

[tor-bugs] #27708 [Core Tor/Tor]: Heap use-after-free on git master dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5

2018-09-14 Thread Tor Bug Tracker & Wiki
#27708: Heap use-after-free on git master 
dbb0abc9f1a174efdb65d581f5dbe46dbad2ebb5
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression, crash
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I found this issue by setting an invalid `HiddenServiceDir` containing 2
 level of directories for tor to create for which it can't do it leading to
 `options_act()` returning -1.

 {{{
 HiddenServiceDir /tmp/level1/level2
 }}}

 Here is the ASAN output:

 {{{
 ==10573==ERROR: AddressSanitizer: heap-use-after-free on address
 0x61d02948 at pc 0x55741b1f88d1 bp 0x7ffe0d70bc10 sp 0x7ffe0d70bc00
 READ of size 8 at 0x61d02948 thread T0
 #0 0x55741b1f88d0 in or_options_free_ src/app/config/config.c:1005
 #1 0x55741b2009af in config_free_all src/app/config/config.c:1034
 #2 0x55741ad38034 in tor_free_all src/core/mainloop/main.c:3693
 #3 0x55741ad38b6e in tor_run_main src/core/mainloop/main.c:4277
 #4 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
 #5 0x55741ad1d7cb in main src/app/main/tor_main.c:32
 #6 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x2409a)
 #7 0x55741ad219e9 in _start
 (/home/dgoulet/Documents/git/tor/src/app/tor+0x9119e9)

 0x61d02948 is located 200 bytes inside of 2264-byte region
 [0x61d02880,0x61d03158)
 freed by thread T0 here:
 #0 0x7fc43614cb70 in free (/usr/lib/x86_64-linux-
 gnu/libasan.so.5+0xedb70)
 #1 0x55741b23e3e7 in config_free_ src/app/config/confparse.c:871
 #2 0x55741b1f8548 in or_options_free_ src/app/config/config.c:1026
 #3 0x55741b22bbcc in options_init_from_string
 src/app/config/config.c:5487
 #4 0x55741b22d540 in options_init_from_torrc
 src/app/config/config.c:5233
 #5 0x55741ad37098 in tor_init src/core/mainloop/main.c:3540
 #6 0x55741ad389c0 in tor_run_main src/core/mainloop/main.c:4275
 #7 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
 #8 0x55741ad1d7cb in main src/app/main/tor_main.c:32
 #9 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x2409a)

 previously allocated by thread T0 here:
 #0 0x7fc43614cf30 in __interceptor_malloc (/usr/lib/x86_64-linux-
 gnu/libasan.so.5+0xedf30)
 #1 0x55741b3b378a in tor_malloc_ src/lib/malloc/malloc.c:45
 #2 0x55741b3b3821 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
 #3 0x55741b22b294 in options_init_from_string
 src/app/config/config.c:5336
 #4 0x55741b22d540 in options_init_from_torrc
 src/app/config/config.c:5233
 #5 0x55741ad37098 in tor_init src/core/mainloop/main.c:3540
 #6 0x55741ad389c0 in tor_run_main src/core/mainloop/main.c:4275
 #7 0x55741ad2286b in tor_main src/feature/api/tor_api.c:164
 #8 0x55741ad1d7cb in main src/app/main/tor_main.c:32
 #9 0x7fc43440109a in __libc_start_main (/lib/x86_64-linux-
 gnu/libc.so.6+0x2409a)

 SUMMARY: AddressSanitizer: heap-use-after-free
 src/app/config/config.c:1005 in or_options_free_
 }}}

 Logs shows:

 {{{
 Sep 14 10:20:00.000 [warn] Error creating directory /tmp/level1/level2: No
 such file or directory
 Sep 14 10:20:00.000 [warn] Error loading rendezvous service keys
 Sep 14 10:20:00.000 [err] set_options(): Bug: Acting on config options
 left us in a broken state. Dying. (on Tor 0.3.5.0-alpha-dev
 dbb0abc9f1a174ef)
 }}}

 What I can tell is that if `options_act()` returns -1, we'll inevitably
 end up in this situation so this isn't HS only. Kind of difficult to
 follow the stacktrace as the use-after-free points to a free(). I know
 that the pointer there is NULL at that time...

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

Re: [tor-bugs] #27686 [Core Tor/Tor]: OOM code should count space used in a circuit's half-closed list

2018-09-14 Thread Tor Bug Tracker & Wiki
#27686: OOM code should count space used in a circuit's half-closed list
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  034-backport?  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 See ticket27686_034 for the branch. It's based on Mikeperry's
 ticket25573-034, and merges cleanly into master.  There's a compilation
 issue post-merge, so I made ticket27686_035 to clean that up. See PR at
 https://github.com/torproject/tor/pull/335 .  No changes file needed if we
 get this in before 0.3.5.1 :)

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

Re: [tor-bugs] #26146 [Applications/Tor Browser]: Setting `general.useragent.override` does not spoof the platform part anymore in ESR 60 which is confusing

2018-09-14 Thread Tor Bug Tracker & Wiki
#26146: Setting `general.useragent.override` does not spoof the platform part
anymore in ESR 60 which is confusing
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-fingerprinting-os, |  Actual Points:
  tbb-8.0-issues, tbb-8.0.1-can, |
  TorBrowserTeam201809R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:63 gk]:
 > Looks mostly good to me. I guess we could refactor
 `Navigator::GetUserAgent()` a bit but we can leave that our for now and
 tackle that when upstreaming this patch.

 Kathy and I were a little afraid to make big changes there without advice
 from a Mozilla person and/or more time to test things.

 > Please adjust the WinXP in the commit message and the title given that
 you delete `general.useragent.override` from the prefs we ship but have
 the bug fixed nevertheless. Maybe "Bug 26146: Spoof HTTP User-Agent header
 for desktop platforms"? (or something like that). Oh, and that's not only
 JavaScript on/off related. The risk we are writing the patch for is that
 the OS is collected by any server Tor Browser is talking to, irrespective
 of your JS settings.

 Here is a revised patch (new commit message):
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug26146-02=a9b83ea79e2e1751d63fffe62b457008d516145e

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

Re: [tor-bugs] #27515 [Applications/Tor Browser]: video placeholder didn't work in Tor browser 8.0 on highest security level

2018-09-14 Thread Tor Bug Tracker & Wiki
#27515: video placeholder didn't work in Tor browser 8.0 on highest security 
level
-+-
 Reporter:  1362572  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, noscript  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by h1n1):

 it also don't work in the normal firefox with noscript, this should be
 related to noscript only

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

2018-09-14 Thread Tor Bug Tracker & Wiki
#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 Replying to [comment:15 ma1]:
 > It should not: NoScript defers all the HTTP(S) traffic until its policy
 is configured and ready to be enforced.
 Ok, so let's say it only breaks in harmless cases. Regardless, it still
 looks like a bug to me: the handler for `fetchChildPolicy` is running
 before making sure the state is properly initialised; for example, the
 object `ns.policy` is used and dereferenced in `getForDocument` even
 though it could still be null. Or maybe I'm wrong, I'm just reading this
 code now.

 > about:blank, data: and file: URLs are those which might suffer of this
 problem, because NoScript has no means to prevent them from loading before
 it's initialized.
 Does that mean that the approach mentioned there [ticket:27553#comment:3]
 is unreliable because of this race?

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

Re: [tor-bugs] #27451 [Core Tor/Tor]: Refactor socket closing in tor_tls_free() so it is not broken with NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27451: Refactor socket closing in tor_tls_free() so it is not broken with NSS
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #27664 [Core Tor/Tor]: Initialization error when using NSS with Chutney

2018-09-14 Thread Tor Bug Tracker & Wiki
#27664: Initialization error when using NSS with Chutney
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  nss   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #27686 [Core Tor/Tor]: OOM code should count space used in a circuit's half-closed list

2018-09-14 Thread Tor Bug Tracker & Wiki
#27686: OOM code should count space used in a circuit's half-closed list
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  034-backport?  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => 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] #27289 [Core Tor/Tor]: Count raw bytes on the wire correctly when using NSS

2018-09-14 Thread Tor Bug Tracker & Wiki
#27289: Count raw bytes on the wire correctly when using NSS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #26631| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by ahf):

 * status:  needs_review => needs_revision


Comment:

 Left some comments on the GH PR.

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

Re: [tor-bugs] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

2018-09-14 Thread Tor Bug Tracker & Wiki
#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance, 035-roadmap-master, 035  |
  -triaged-in-20180711   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #25610 [Core Tor/Tor]: module: Modularized directory authority subsystem

2018-09-14 Thread Tor Bug Tracker & Wiki
#25610: module: Modularized directory authority subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  modularization, 034-roadmap- |  Actual Points:
  subtask, tor-dirauth, 034-triage-20180328, |
  034-included-20180328  |
Parent ID:  #21814   | Points:
 Reviewer:  nickm|Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * parent:  #25494 => #21814


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

Re: [tor-bugs] #26630 [Core Tor/Tor]: Profile-driven work to reduce memory usage, focusing on clients and mobile.

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

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


Comment:

 We've done a fair bit of this, especially the children of #27243; more can
 come in 0.3.6.

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

Re: [tor-bugs] #21814 [Core Tor/Tor]: Reduce binary size for client-only tor

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

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


Comment:

 We've done a fair bit of this; any more can come in 0.3.6

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

Re: [tor-bugs] #26510 [Core Tor/Tor]: Make "bloomfilter set" code first-class

2018-09-14 Thread Tor Bug Tracker & Wiki
#26510: Make "bloomfilter set" code first-class
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  refactoring   |  Actual Points:
Parent ID:  #21814| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

 * parent:   => #21814


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

Re: [tor-bugs] #26631 [Core Tor/Tor]: Allow Tor to build with NSS instead of OpenSSL

2018-09-14 Thread Tor Bug Tracker & Wiki
#26631: Allow Tor to build with NSS instead of OpenSSL
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #21814   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * parent:  #26639 => #21814


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #25497, #25499, #26288, #26296, ...

2018-09-14 Thread Tor Bug Tracker & Wiki
Batch modification to #25497, #25499, #26288, #26296, #27530, #25269, #16824, 
#17949, #21039, #24546, #24732, #24586, #26636, #27225, #27248 by nickm:
milestone to Tor: 0.3.6.x-final

Comment:
Deferring various feature-y things to 0.3.6.  If one of these is actually 
happening in 0.3.5, please let me know!

--
Tickets URL: 

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

Re: [tor-bugs] #27507 [Applications/Tor Browser]: DuckDuckGo can't be used without JS in Tor Browser 8 anymore

2018-09-14 Thread Tor Bug Tracker & Wiki
#27507: DuckDuckGo can't be used without JS in Tor Browser 8 anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, tbb-8.0.1-can, GeorgKoppen201809,  |
  TorBrowserTeam201809   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by h1n1):

 this occurs every time that put at safest level
 I have to close and reopen for work properly

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

Re: [tor-bugs] #27507 [Applications/Tor Browser]: DuckDuckGo can't be used without JS in Tor Browser 8 anymore

2018-09-14 Thread Tor Bug Tracker & Wiki
#27507: DuckDuckGo can't be used without JS in Tor Browser 8 anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, tbb-8.0.1-can, GeorgKoppen201809,  |
  TorBrowserTeam201809   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by h1n1):

 1. start TB
 2. set safest security level
 3. search at duckduckgo
 it will break
 than close and reopen
 it will works
 TB is requiring reopening for work properly at safety level

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

Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

2018-09-14 Thread Tor Bug Tracker & Wiki
#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rustybird):

 Replying to [comment:15 ma1]:
 > Replying to [comment:14 rustybird]:
 >
 > > If this race hypothetically affects real websites (i.e. not just
 `about:blank` and empty `data:` pages),
 >
 > It should not: NoScript defers all the HTTP(S) traffic until its policy
 is configured and ready to be enforced.
 > about:blank, data: and file: URLs are those which might suffer of this
 problem, because NoScript has no means to prevent them from loading before
 it's initialized.

 Thanks, that makes sense.

 Replying to [comment:13 ma1]:
 > So, if the Tor Browser can start using `__meta.name` both on the
 receiving and the sending end, I'm gonna get rid of the "legacy" redundant
 `_messageName` property in one of the next releases.

 I've uploaded a
 [https://trac.torproject.org/projects/tor/attachment/ticket/27427/v3-Fix-
 NoScript-IPC-for-about-blank-by-whitelisting-messages.patch v3 patch for
 the receiving end] and a
 [https://trac.torproject.org/projects/tor/attachment/ticket/27427/Send-
 updateSettings-message-using-NoScript-10.1.9.2-protocol.patch patch for
 the sending end].

 Assuming that these patches land in Tor Browser 8.0.**1**, maybe NoScript
 could keep the legacy code for a little while, e.g. until Tor Browser
 8.0.**2** is released. This would be a grace period for Tor Browser
 8.0**(.0)** users, so they don't automatically receive an NoScript
 extension update to an incompatible version.

 Replying to [comment:10 arthuredelstein]:
 > I changed it to use the better JS equality operator

 Whoops yes, `==` is crappy. The v3 patch uses `Array.prototype.includes()`
 to make it shorter, so it's like `===` except that `NaN` would be
 considered equal to itself. Hope that's okay, I can change it if 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] #27335 [Core Tor/Tor]: Tor bug when hs directory is missing

2018-09-14 Thread Tor Bug Tracker & Wiki
#27335: Tor bug when hs directory is missing
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.6-rc
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Ok so another thing pointed out by traumschule on IRC.

 We shouldn't have the `BUG()` there because it will fail if the directory
 did not exists before. In `hs_config.c`, we don't try to create it so the
 check will pass if it doesn't exists, and then when loading the keys,
 we'll create the directory but we could still have the permission issues
 leading to the `BUG()` being triggered but shouldn't have.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #25501, #26632, #26633, #26634

2018-09-14 Thread Tor Bug Tracker & Wiki
Batch modification to #25501, #26632, #26633, #26634 by nickm:
milestone to Tor: 0.3.6.x-final

Comment:
Defer remaining wtf-pad tickets from 0.3.5 to 0.3.6

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #23061, #25263, #26945, #26957, ...

2018-09-14 Thread Tor Bug Tracker & Wiki
Batch modification to #23061, #25263, #26945, #26957, #26970, #26973, #26939, 
#26940, #26943, #25669, #26958, #22898, #26637 by nickm:
milestone to Tor: 0.3.6.x-final

Comment:
Deferring privcount tickets in 0.3.5 to 0.3.6

--
Tickets URL: 

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

Re: [tor-bugs] #21530 [Core Tor/Tor]: Make ExitRelay 0 the default when there is no exit policy

2018-09-14 Thread Tor Bug Tracker & Wiki
#21530: Make ExitRelay 0 the default when there is no exit policy
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-exit tor-relay configuration |  implemented
  usability expectations |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Looks good!  I've merged, and tweaked a little:
* I changed the log message to explain how to suppress it.
* I made it so the log message only appears if you're running as a
 public relay.  (If you're running as a client, you probably don't expect
 to be an exit.)
* I tweaked the changes file's severity so it will be more prominent.

 Thanks for 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] #27687 [Core Tor/Tor]: rust protover accepts non ASCII in protocol names

2018-09-14 Thread Tor Bug Tracker & Wiki
#27687: rust protover accepts non ASCII in protocol names
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  rust, protover, 033-backport,|  Actual Points:
  034-backport   |
Parent ID:  #27316   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to 0.3.3 and forward. 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] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

2018-09-14 Thread Tor Bug Tracker & Wiki
#27691: reset bootstrap progress when enough things change
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap   |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by mcs):

 * cc: linda (removed)
 * cc: antonela (added)


Comment:

 Replying to [comment:1 catalyst]:
 > Upon reviewing the comments in #22266 some more, it seems like users may
 be upset by seeing progress reset to zero after making a configuration
 change.
 >
 > I think it's an accurate reflection of what's going on.  Going to the
 config dialog sets DisableNetwork=1 and tears down the circuits and TCP
 connections, which have to be set up again.

 I think the progress displayed by Tor Launcher should be an accurate
 reflection of the internal tor state. If that means resetting to zero, so
 be it. That said, the nature of the network is that sometimes progress
 occurs more quickly than at other times, which can be confusing. For
 example, if someone makes a configuration change in the hope of improving
 things but progress is slower than before due to other factors the user
 may incorrectly conclude that the new configuration is worse. I am not
 sure how to address that though.

 > Maybe if there's additional UI in Tor Launcher to show the existence of
 cached directory info, that will make it less likely for users to be
 frustrated by apparently negative progress?  That's a longer term change,
 though.

 Agreed; exposing more details about what is going on inside tor would be
 interesting and helpful for advanced users (and support people) at least.

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

Re: [tor-bugs] #27678 [Core Tor/Tor]: Emit CIRC_BW event early for dropped cells

2018-09-14 Thread Tor Bug Tracker & Wiki
#27678: Emit CIRC_BW event early for dropped cells
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Seems reasonable to me too. 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] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

2018-09-14 Thread Tor Bug Tracker & Wiki
#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-+-
 Reporter:  rustybird|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201809R,   |  Actual Points:
  tbb-8.0.1-can  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by rustybird):

 * Attachment "Send-updateSettings-message-using-
 NoScript-10.1.9.2-protocol.patch" added.


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

  1   2   >