Re: [tor-bugs] #20556 [Applications/Tor bundles/installation]: pt-PT Tor Browser bundles are diguised pt-BR bundles

[Tor Bug Tracker & Wiki]

#20556: pt-PT Tor Browser bundles are diguised pt-BR bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201611R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:8 gk]:
 >
 > Yes, they should probably get the full pt-BR .mar file. I guess there is
 just some server-side tweaking necessary? If so, could you take care of
 it?

 The branch `bug_20556_update_responses` has a patch for this:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_20556_update_responses

 After renaming the pt-PT mar files to pt-BR and running `make
 update_responses-alpha` with this patch, I get an `.htaccess` file
 containing new lines such as:
 {{{
 RewriteRule ^Linux_x86-gcc3/[^/]+/pt-PT 6.5a3-linux32-pt-BR.xml [last]
 }}}

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

Re: [tor-bugs] #19875 [Core Tor/Tor]: shuffle our bridges when we load them from config

[Tor Bug Tracker & Wiki]

#19875: shuffle our bridges when we load them from config
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pastly):

 This is interesting to me. I'm going to see if I have time to test
 hdevalence's branch and write tests.

 Replying to [comment:5 isis]:
 > Replying to [comment:3 hdevalence]:
 > > Also, should this behaviour be configurable, instead of always-on?  Do
 people rely on bridge ordering?
 >
 > It seems like a good idea to make it configurable, but off-by-default.
 This way, we can preserve the currently expected behaviour without
 surprising users. We can revert my patch in #18113 and just flip the
 config variable on for TB users, and, likewise, non-TB users who really
 want this can opt-in to enabling it.
 >
 > (I'm willing to be talked out of this viewpoint if there's good reason
 to do otherwise.)
 >

 How much do we care about people who use non-default torrcs for the TBB?
 The only concern I want to raise is that if enough people remove the
 ShuffleBridges option and #18113 is reverted, then there could be unfair
 load on the first few bridges again.

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: PK11_DigestFinal crash in Tor Browser on OSX

[Tor Bug Tracker & Wiki]

#20390: PK11_DigestFinal crash in Tor Browser on OSX
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 https://crash-stats.mozilla.com/report/index/adc40c89-dfdc-
 45ba-8503-dc5912160918
 backtrace differs but is about wrong slot for cx->slot->isThreadSafe 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] #20596 [Metrics]: add jdk version to manifest files

[Tor Bug Tracker & Wiki]

#20596: add jdk version to manifest files
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 That looks fine!

 The attribute is only necessary for the class file jar, but I didn't write
 that.

 Do you mind adding two more attributes?

 In total these lines:

 {{{
 
 
 
 }}}

 i.e.
 {{{
 #!diff
   
   
  +
  +
  +
 
   
   
 }}}

 jvm vendor and name might be useful, 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] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:7 rubiate]:
 > +#define TOO_OLD_WARNING_TIMEOUT 60*60

 Putting parens around this value will make you a happier camper in the
 future. The above line is straight out of some arithmetic precedence
 example bug.

 Also, for your {{{static time_t warned}}}, did you know about the
 rate_limit_log() function? It might be what you wanted here.

 > +  format_local_iso_time(timestamp, v->valid_until);
 > +  log_fn(severity, LD_DIRSERV,
 > + "Our %s%sconsensus is too old, we will not serve it to
 clients. "
 > + "It was valid until %s and we continued to serve it for up to
 24 "
 > + "hours after it expired.",
 > + flavor ? flavor : "", flavor ? " " : "", timestamp);

 A) s/old, we/old, so we/

 B) I think format_local_iso_time() produces a time in the local time zone,
 right? So we should clarify in the log message by adding a phrase like
 "(in local time zone)". Otherwise we've left it ambiguous whether we mean
 the UTC time that consensuses use, or the local time that log lines
 sometimes use.

 > +  tor_free(header);
 > +  header = NULL;

 tor_free sets its argument to NULL already, right?

 Good to see unit tests!

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

Re: [tor-bugs] #20254 [Applications/Quality Assurance and Testing]: Update marsigning-check.sh to cope with signed OS X MAR files

[Tor Bug Tracker & Wiki]

#20254: Update marsigning-check.sh to cope with signed OS X MAR files
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by gk:

Old description:

> Now that the fix for #19410 landed out `marsigning-check.sh` script can't
> check the correctness of our MAR file signatures easily anymore as we use
> the SHA256 sums of the unsigned MAR files currently. We should adapt the
> script.

New description:

 Now that the fix for #19410 landed our `marsigning-check.sh` script can't
 check the correctness of our MAR file signatures easily anymore as we use
 the SHA256 sums of the unsigned MAR files currently. We should adapt the
 script.

--

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: PK11_DigestFinal crash in Tor Browser on OSX

[Tor Bug Tracker & Wiki]

#20390: PK11_DigestFinal crash in Tor Browser on OSX
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 https://crash-stats.mozilla.com/report/index/0c05437b-1b2b-
 44b8-b886-2d77f2160803
 this wrong slot for cx->slot->isThreadSafe 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] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Sure, missed this update. Was working on building the job already.

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: PK11_DigestFinal crash in Tor Browser on OSX

[Tor Bug Tracker & Wiki]

#20390: PK11_DigestFinal crash in Tor Browser on OSX
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 https://crash-stats.mozilla.com/report/index/e2d790c0-36de-
 412e-b485-36b7d2160718
 this 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] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:8 teor]:
 > I am not sure whether we should backport this to 0.2.9, but given that's
 where the trouble started, maybe it would be a good idea to do that as a
 precaution.

 I would turn that around and ask: is it likely that there's a bug in 0.2.9
 that *isn't* in 0.3.0? That angle makes me think 0.3.0 is fine.

 That said, I'm ok with either plan.

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

Re: [tor-bugs] #20390 [Applications/Tor Browser]: PK11_DigestFinal crash in Tor Browser on OSX

[Tor Bug Tracker & Wiki]

#20390: PK11_DigestFinal crash in Tor Browser on OSX
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Another similar crash report https://crash-
 stats.mozilla.com/report/index/12e447c0-b561-4a53-ad94-ea6e72160702
 Crash Address - eax = 0x30 too, offset for `slot`.

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

Re: [tor-bugs] #20366 [Applications/Tor Browser]: NoScript allows all 3rd party scripts when base domain is blocked

[Tor Bug Tracker & Wiki]

#20366: NoScript allows all 3rd party scripts when base domain is blocked
--+-
 Reporter:  joebt |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  NoScript, Cascade, 3rd party  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by joebt):

 I didn't discuss it directly with Giorgio, but NoScript forum's long time
 main moderator, barbaz, claimed this feature  "Cascade top document's
 permissions" was introduced at Tor devs' request.

 I haven't confirmed that. If true, one question is, was this behavior
 under a specific condition what Tor Project wanted or even considered?
 Whether if a base domain is blocked, all 3rd party sites should be
 '''shown''' as allowed or blocked.

 When base domain is blocked, not sure if allowed 3rd party sites / scripts
 would '''ever''' under any circumstance be able to execute under NS or
 TBB.  Key phrase is "ever under any circumstance," vs. "probably won't."

 Barbaz gave no real explanation - why or when the described behavior would
 be desirable or expected by most users.

 Even if 3rd party scripts could '''never''' execute when a base domain is
 blocked, showing them as "allowed" is probably disconcerting and not what
 users prefer to see.  Far less significant GUI quirks than this have been
 fixed.

 If enabling some TBB / Tor Button option made it incorrectly show "You are
 NOT connected to Tor network," most users wouldn't want to  ignore that as
 just a quirk.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20608 [Applications/Tor Messenger]: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2

[Tor Bug Tracker & Wiki]

#20608: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2
-+-
 Reporter:  madystar |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Messenger  |   Keywords:  MathJax, addons, tor-
 Severity:  Normal   |  messenger
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When I first searched it on the Add-ons menu I could not find it. I had to
 directly download it from the instantbird plugins website at this address:

 https://addons.instantbird.org/en-US/instantbird/addon/340

 I then used the "Install Add-on from file" in the Add-ons menu but then I
 got the following error:

 > MathJax LaTeX could not be installed because it is not compatible with
 Tor Messenger  0.2.0b2.

 It would be really great if this issue could be resolved, since it's
 practically impossible to chat about maths without MathJax.

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201611   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:13 boklm]:
 > In the new nightly build (in which this change has been merged), I see
 that when changing the `extensions.torbutton.security_slider` preference
 from outside the browser (by editing
 `Browser/TorBrowser/Data/Browser/profile.default/preferences/extension-
 overrides.js` while the browser is not running), the new slider mode is
 not applied when starting the browser. It is still applied correctly when
 changing it from about:config or from the slider dialog.

 Thanks for finding this bug, boklm. Here's a patch to fix it.
 https://github.com/arthuredelstein/torbutton/commit/20347+2

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201611   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  reopened => 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] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

[Tor Bug Tracker & Wiki]

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tnoisu):

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


Comment:

 Hi, I can't login into my old account ''tagener-noisu'', so I have created
 another one. The problem was that meek wasn't able to create a log file in
 the working directory. I've changed log path like this `--log /tmp/meek-
 client.log` to fix it. I think that meek should just work without logging
 if it couldn't create a log file. Should I report this issue to
 developer's github?

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

Re: [tor-bugs] #20608 [Applications/Tor Messenger]: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2

[Tor Bug Tracker & Wiki]

#20608: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2
+-
 Reporter:  madystar|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  MathJax, addons, tor-messenger  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by madystar):

 Forgot to precise: This add-on works perfectly with Instantbird.

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

Re: [tor-bugs] #20439 [Applications/Tor Browser]: The firefox binary in Tor Browser on OSX is not PIE

[Tor Bug Tracker & Wiki]

#20439: The firefox binary in Tor Browser on OSX is not PIE
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-hardened, TorBrowserTeam201611R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-hardened => tbb-hardened, TorBrowserTeam201611R
 * status:  new => needs_review


Comment:

 I attached 2 patches to this ticket:
 - `tor-browser-0001-Bug-20439-make-the-build-PIE-on-OSX.patch` is a patch
 for `tor-browser.git` adding `-Wl,-pie` to `LDFLAGS`.
 - ` tor-browser-bundle-0001-Bug-20439-make-the-build-PIE-on-OSX.patch` is
 a patch for `builders/tor-browser-bundle.git` creating wrappers on `clang`
 and `clang++` to add the `-fPIE` flag.

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3

[Tor Bug Tracker & Wiki]

#20250: meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This should be fixed in 6.0.6 and 6.5a4.

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

Re: [tor-bugs] #20023 [Applications/Tor Browser]: Upgrade Go to 1.7.3

[Tor Bug Tracker & Wiki]

#20023: Upgrade Go to 1.7.3
--+
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-gitian TorBrowserTeam201611R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 I put the fix into maint-6.0 as well with commits
 3dee56db1330daa8df7e4d0c90d88bff17b80fec and
 4a0bf1ed2578e3e742e00f95385f914a241904fd.

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, prop224,  |  Actual Points:
  proposal, TorCoreTeam201611|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Tor patch: `ticket19642_030_01`
 Spec patch: `ticket19642_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] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 Replying to [comment:10 hiro]:
 > Sure, missed this update. Was working on building the jobs already.

 Thanks for taking this task!  I'll set it on assigned.

 > One question I have is regarding necessary jars that are needed to build
 and run the test task. Some of these are included in debian stable, but
 not w/ the same version needed to build metrics-lib or collector.

 I thought the versions of all jars used for `compile` and `test` were
 available in debian jessie.
 Could you post the list of different versions on the test system?  So, I
 can check the build and alter the dependencies if necessary.

 >  Shall these be included manually?
 Is there a way of adding non-debian-stable jars to builds?
 I thought that option was ruled out for administrative reasons.

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

Re: [tor-bugs] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-+--
 Reporter:  karsten  |  Owner:  hiro
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


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

Re: [tor-bugs] #20414 [Applications/Tor Browser]: Donation banner on about:tor page for 2016 campaign

[Tor Bug Tracker & Wiki]

#20414: Donation banner on about:tor page for 2016 campaign
+--
 Reporter:  arthuredelstein |  Owner:
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201611, crowdfunding  |  Actual Points:
Parent ID:  #20413  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 Replying to [comment:12 gk]:
 > okay, I gave it a whirl and it looks good to me with some nits
 addressed:

 Thanks for the review.

 > 1) What is the scope of `count`?

 Fixed.

 > 2) s/that stop observing/that stops observing/

 Fixed.

 > 3) We put in the translations early to give translators time to produce
 the properly localized strings for non en-US Tor Browser versions. Yet the
 code is only concerned with en-US bundles anyway. What is the plan here
 then? Don't we want to ship 6.0.6 with the donation banner enabled for as
 many users as possible (this is more a needs_information point as I am not
 sure whether we should fix the code or not)?

 I have currently added several locales. I hope more can be translated in
 time for the release (including French and Russian). If so, we'll need to
 add those to the `kBannerLocales` list when they are ready.

 New version: https://github.com/arthuredelstein/torbutton/commit/20414+11

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

Re: [tor-bugs] #20414 [Applications/Tor Browser]: Donation banner on about:tor page for 2016 campaign

[Tor Bug Tracker & Wiki]

#20414: Donation banner on about:tor page for 2016 campaign
+--
 Reporter:  arthuredelstein |  Owner:
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201611, crowdfunding  |  Actual Points:
Parent ID:  #20413  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arthuredelstein):

 * status:  needs_revision => 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] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, prop224,  |  Actual Points:
  proposal, TorCoreTeam201611|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by dgoulet):

 Ok, I've added nickm's suggestion clarifying that this will be for onion
 service >= 0.3.0 as I'm about to work on the patch for inclusion in 030.

 If no objection, I'll merge this branch to torspec: `ticket19642_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] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-+--
 Reporter:  karsten  |  Owner:  hiro
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 The build.xml file has different paths for different tasks.

 Currently, we're excluding checkstyle (cf. description) as this is indeed
 not in debian jessie.

 The path for compile and test tasks are [https://gitweb.torproject.org
 /metrics-lib.git/tree/build.xml#n35 classpath] and
 [https://gitweb.torproject.org/metrics-lib.git/tree/build.xml#n48
 test.classpath].
 The [https://gitweb.torproject.org/metrics-lib.git/tree/build.xml#n63
 cobertura.classpath] ought to be fine, but I'm not 100% sure.

 It would be nice to have the results of the following tasks available
 after a run:
 * `ant test`
 * `ant coverage`
 * `ant docs`

 I assume the Jenkins build slave environment is empty before a build.  If
 not, the task `ant clean` needs to run first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20609 [User Experience/Website]: Donation page 2016 redirects

[Tor Bug Tracker & Wiki]

#20609: Donation page 2016 redirects
-+---
 Reporter:  arthuredelstein  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #20413
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 For the donation banner, we want to use similar redirects as before. This
 time the donation page will be at https://donate.torproject.org . That
 page is not quite ready yet, so we'll need to wait to make these redirects
 live. The launch date is November 15, but I hope the donation page will be
 ready at least a few days before that. If the donation page gets localized
 at some point, then we can change the redirect targets to the localized
 versions.

 The format of the redirect URLs should be

 https://www.torproject.org/donate/donate-TYPE-LOCALE

 Where the possible values for TYPE are:
 tbb
 homepage
 twitter
 fb
 blog

 And possible values for LOCALE are:
 ar
 de
 en
 es
 fa
 fr
 it
 ja
 ko
 nl
 pl
 pt
 ru
 tr
 vi
 zh

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

Re: [tor-bugs] #20568 [Core Tor/Tor]: Move encode_cert() from hs_descriptor.c into torcert.c

[Tor Bug Tracker & Wiki]

#20568: Move encode_cert() from hs_descriptor.c into torcert.c
---+---
 Reporter:  dgoulet|  Owner:
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, easy, refactoring  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorR-can
---+---
Changes (by dgoulet):

 * status:  new => needs_revision


Comment:

 Thanks for this neel!

 * DG1: I would rename the function to something more meaningful as this
 function encoded an ed25519 certificate which is pretty specific and also
 should follow the torcert.c namespace. Maybe `tor_cert_encode_ed22519()` ?

 * DG2: You can remove it from `hs_descriptor.h` instead of commenting it
 out.

 * DG3: We have to change this log message to be a bit more generic as it's
 very specific to HS right now.
 {{{
 log_err(LD_BUG, "Couldn't base64-encode descriptor signing key
 cert!");
 }}}

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

Re: [tor-bugs] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

[Tor Bug Tracker & Wiki]

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Please find a [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20521-2=c8707e56904119fc072b700b9f839ac371c1d83e
 commit] on top of your branch with some modernization (reduced number of
 lines) and a checkstyle complaint removed.

 Wouldn't this be the right time to add a test class for
 `DescriptorReader`(Impl)?

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

Re: [tor-bugs] #8387 [Core Tor/Tor]: Unbuilt one-hop circuits sometimes hang around forever

[Tor Bug Tracker & Wiki]

#8387: Unbuilt one-hop circuits sometimes hang around forever
-+-
 Reporter:  mikeperry|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-triaged, |  Actual Points:
  027-triaged-1-out 2016-bug-retrospective   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pastly):

 I'm getting output related to this ticket every heartbeat it looks like.
 Running 0294-alpha as a single onion service.

 The real-time up-to-date log is http://bh2lpa5qyawryvk2.onion/log

 Tor 0.2.9.4-alpha (git-8b0755c9bb296ae2) running on Linux with Libevent
 2.0.10-stable, OpenSSL 1.0.1t and Zlib 1.2.8.

 Snippit:

 {{{
 Nov 07 07:50:00.000 [notice] Heartbeat: Tor's uptime is 9 days 11:59
 hours, with 10 circuits open. I've sent 38.40 MB and received 122.33 MB.
 Nov 07 07:50:00.000 [notice] Diagnostic for issue 8387: Found 3 one-hop
 circuits more than 1800 seconds old! Logging 3...
 Nov 07 07:50:00.000 [notice]   #0 created at 2016-11-06 23:49:39. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 07:50:00.000 [notice]   #1 created at 2016-11-06 18:23:40. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 07:50:00.000 [notice]   #2 created at 2016-11-07 05:29:55. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 07:50:00.000 [notice] It has been 11 seconds since I last called
 circuit_expire_old_circuits_clientside().
 Nov 07 10:07:03.000 [warn] Giving up launching first hop of circuit to
 rendezvous point [scrubbed] for service bh2lpa5qyawryvk2.
 Nov 07 10:07:14.000 [warn] Giving up launching first hop of circuit to
 rendezvous point [scrubbed] for service bh2lpa5qyawryvk2.
 Nov 07 10:07:44.000 [warn] Giving up launching first hop of circuit to
 rendezvous point [scrubbed] for service bh2lpa5qyawryvk2.
 Nov 07 10:08:23.000 [warn] Giving up launching first hop of circuit to
 rendezvous point [scrubbed] for service bh2lpa5qyawryvk2.
 Nov 07 13:50:00.000 [notice] Heartbeat: Tor's uptime is 9 days 17:59
 hours, with 6 circuits open. I've sent 39.17 MB and received 124.90 MB.
 Nov 07 13:50:00.000 [notice] Diagnostic for issue 8387: Found 3 one-hop
 circuits more than 1800 seconds old! Logging 3...
 Nov 07 13:50:00.000 [notice]   #0 created at 2016-11-06 23:49:39. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 13:50:00.000 [notice]   #1 created at 2016-11-06 18:23:40. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 13:50:00.000 [notice]   #2 created at 2016-11-07 05:29:55. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 13:50:00.000 [notice] It has been 4 seconds since I last called
 circuit_expire_old_circuits_clientside().
 Nov 07 19:01:32.000 [warn] connection_edge_process_relay_cell (at origin)
 failed.
 Nov 07 19:50:00.000 [notice] Heartbeat: Tor's uptime is 9 days 23:59
 hours, with 6 circuits open. I've sent 40.01 MB and received 128.15 MB.
 Nov 07 19:50:00.000 [notice] Diagnostic for issue 8387: Found 3 one-hop
 circuits more than 1800 seconds old! Logging 3...
 Nov 07 19:50:00.000 [notice]   #0 created at 2016-11-06 23:49:39. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 19:50:00.000 [notice]   #1 created at 2016-11-07 16:01:03. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 19:50:00.000 [notice]   #2 created at 2016-11-07 05:29:55. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 Nov 07 19:50:00.000 [notice] It has been 28 seconds since I last called
 circuit_expire_old_circuits_clientside().
 Nov 08 01:50:00.000 [notice] Heartbeat: Tor's uptime is 10 days 5:59
 hours, with 7 circuits open. I've sent 40.93 MB and received 131.47 MB.
 Nov 08 01:50:00.000 [notice] Diagnostic for 

Re: [tor-bugs] #20564 [Metrics]: Add Jenkins configuration for running metrics-lib's unit tests and producing a .jar file

[Tor Bug Tracker & Wiki]

#20564: Add Jenkins configuration for running metrics-lib's unit tests and
producing a .jar file
-+--
 Reporter:  karsten  |  Owner:  hiro
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 Thanks iwakeh.
 One example that I found is: https://packages.debian.org/jessie/checkstyle
 We require v6.17 that isn't available on jessie. I will make a complete
 list and update this ticket.

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

Re: [tor-bugs] #20608 [Applications/Tor Messenger]: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2

[Tor Bug Tracker & Wiki]

#20608: MathJax LaTeX plugin is not compatible with Tor Messenger 0.2.0b2
+
 Reporter:  madystar|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  MathJax, addons, tor-messenger  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Thanks for reporting!

 The problem is that we were setting the app version to Tor Messenger's,
 rather than Instantbird's, so the add-on manager considered it invalid for
 that version.

 Fixed in https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=ec41e467065ab4c8d5b64e0b2b8f16fe5c1a2871

 That patch should go out in next week's update.  If you want to get this
 working sooner, you download the add-on from the page you linked to above.
 Extract it (rename .xpi to .zip, and unzip).  Edit the file called
 `install.rdf`,

 {{{
 0
 *
 }}}

 Then, inside the extracted directory, run `zip -r
 mathjax_latex-1.6-instantbird.xpi *` to recreate the .xpi

 You can then install from file, as you did above.

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

Re: [tor-bugs] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+---
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Yes, sounds 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] #20568 [Core Tor/Tor]: Move encode_cert() from hs_descriptor.c into torcert.c

[Tor Bug Tracker & Wiki]

#20568: Move encode_cert() from hs_descriptor.c into torcert.c
---+---
 Reporter:  dgoulet|  Owner:
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, easy, refactoring  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorR-can
---+---

Comment (by neel):

 I have made an updated patch for this. Keep in mind that it is just
 additions to the first patch, but the changes you requested were made.

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

Re: [tor-bugs] #15813 [Metrics/Onionoo]: onionoo instances have distinct contact string encoding

[Tor Bug Tracker & Wiki]

#15813: onionoo instances have distinct contact string encoding
-+---
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Yep, this issue still exist.  Random example:

 {{{
 
https://onionoo.torproject.org/details?lookup=FB0F1F4E1DE3E81A990A75D02C28EAB6A66FF1AD
"contact": "Random Person ",

 
https://onionoo.thecthulhu.com/details?lookup=FB0F1F4E1DE3E81A990A75D02C28EAB6A66FF1AD
   "contact": "Random Person ",
 }}}

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  TorBrowserTeam201611R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => closed
 * keywords:  tbb-usability, tbb-security-slider, TorBrowserTeam201611 =>
 tbb-usability, tbb-security-slider, TorBrowserTeam201611R
 * resolution:   => fixed


Comment:

 Yay, for having tests! Applied to master (commit
 595b01456eaa3b0759f1f80d562ebf6520c8c182).

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

Re: [tor-bugs] #3246 [Applications/Tor Browser]: Isolate HTTP cookies according to first and third party domain contexts

[Tor Bug Tracker & Wiki]

#3246: Isolate HTTP cookies according to first and third party domain contexts
-+-
 Reporter:  mikeperry|  Owner:  michael
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  backport-to-mozilla, tbb-|  Actual Points:
  linkability, tbb-usability-website, tbb-   |
  bounty, tbb-firefox-patch, ff52-esr-will-have  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 backport-to-mozilla, tbb-linkability, tbb-usability-website, tbb-
 bounty, tbb-firefox-patch
 =>
 backport-to-mozilla, tbb-linkability, tbb-usability-website, tbb-
 bounty, tbb-firefox-patch, ff52-esr-will-have
 * severity:   => Normal


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

Re: [tor-bugs] #20596 [Metrics]: add jdk version to manifest files

[Tor Bug Tracker & Wiki]

#20596: add jdk version to manifest files
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Wait, to be clear: these three attributes should only be added to the .jar
 file with class files and '''not''' to the .jar files with sources and
 with javadocs?

 Somewhat off-topic: does this change mean that I should build future
 releases in a Debian stable VM, not in macOS, for maximum reproducibility?

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

Re: [tor-bugs] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

[Tor Bug Tracker & Wiki]

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => new


Comment:

 Replying to [comment:3 iwakeh]:
 > Please find a [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20521-2=c8707e56904119fc072b700b9f839ac371c1d83e
 commit] on top of your branch with some modernization (reduced number of
 lines) and a checkstyle complaint removed.

 Oops, I totally missed that checkstyle complaint.  But I think your fix
 only removes the complaint and lets Javadoc think that the `@deprecated`
 line is yet another paragraph, which is not what we want.  Indenting the
 two lines below that line is the better fix.  Removed that part from your
 commit and added a fixup commit to remove the checkstyle warning.

 I also found that you're using `Files` methods that are introduced in Java
 8, but we're still at Java 7.  Well, Eclipse found that for me.  I added
 another fixup commit for those.  Can you configure your IDE to use the
 Java 7 SE library?  (But okay, I won't say anything after complaining
 about unresolved checkstyle warnings in other patches and then overlooking
 one myself, heh.)

 Please find [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-20521 my updated task-20521 branch].

 > Wouldn't this be the right time to add a test class for
 `DescriptorReader`(Impl)?

 H, yes.  Setting this ticket to new and not merging yet until we
 have such a test class.

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

Re: [tor-bugs] #20585 [Applications/Tor Browser]: HTTPS Everywhere is not working in Tor Browser nightly

[Tor Bug Tracker & Wiki]

#20585: HTTPS Everywhere is not working in Tor Browser nightly
--+--
 Reporter:  boklm |  Owner:  legind
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by legind):

 Just pushed to Tor HTTPSE master - care to verify the build is passing and
 close if so?

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

Re: [tor-bugs] #20560 [Core Tor/Tor]: Some unit tests fail when logging messages on Windows / MinGW64

[Tor Bug Tracker & Wiki]

#20560: Some unit tests fail when logging messages on Windows / MinGW64
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  windows, mingw64, test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 Thanks for the review; I'll merge it and hope.  (I've confirmed that msvc
 does indeed support va_copy and friends.)

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, prop224,  |  Actual Points:
  proposal, TorCoreTeam201611|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:27 dgoulet]:
 > Tor patch: `ticket19642_030_01`

 If `rend_service_non_anonymous_mode_enabled()` is true, we should set
 `desc->encrypted_data.single_onion_service` to 1.

 > Spec patch: `ticket19642_01`

 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] #9612 [Core Tor/Tor]: Wrong IP used from /etc/hosts

[Tor Bug Tracker & Wiki]

#9612: Wrong IP used from /etc/hosts
--+--
 Reporter:  massar|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:2 arma]:
 > The old answer here is "you didn't set your Address line, so what did
 you expect?"
 >
 > I wonder if the new answer should be that we look at the IP address you
 used in your ORPort line, if present, and prefer that guess over the "ask
 for our hostname, then try to resolve it" heuristic.
 >
 > (That new answer is newly possible now that ORPorts can have IP
 addresses in them too.)

 There's an existing ticket for this, #19919.

 > That said, am I right that the {{{ORPort 192.0.2.1:443}}} syntax is bad
 news because it (maybe surprisingly) doesn't listen on 0.0.0.0, so e.g. it
 won't listen on localhost? If so I would argue that people who are trying
 to set their Address line by putting an IP address in the ORPort line are
 doing it wrong.
 >
 > I guess a much simpler first step could be to notice when the operator
 puts an IP address in ORPort or DirPort, but *doesn't* set their Address
 line, and give them a warning?

 We implemented this in 0.2.9 in #13953.

 Is this ticket now a duplicate? (Or now fixed?)
 We also have #17765 and #17782.

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

Re: [tor-bugs] #13386 [Core Tor/Tor]: "opening new log file" line goes to err-logfile despite being at loglevel notice

[Tor Bug Tracker & Wiki]

#13386: "opening new log file" line goes to err-logfile despite being at 
loglevel
notice
--+--
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi Roger. If the concern is that a 'notice' entry goes to the err log then
 why not fix this by sending it to the notice log instead? Is there a
 reason to change the line content?

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

Re: [tor-bugs] #13386 [Core Tor/Tor]: "opening new log file" line goes to err-logfile despite being at loglevel notice

[Tor Bug Tracker & Wiki]

#13386: "opening new log file" line goes to err-logfile despite being at 
loglevel
notice
--+--
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 No, it is not that a notice log line goes to the wrong log file. It is a
 special log line added to a newly made log file so it won't be empty.

 See my above comment again. Then look at
 https://gitweb.torproject.org/tor.git/tree/src/common/log.c?id=tor-0.2.8.9#n235

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

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID:  #20534 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  accepted => closed
 * resolution:   => fixed
 * parent:   => #20534


Comment:

 Fixed, reparenting to #20534 for documentation

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

Re: [tor-bugs] #20559 [Core Tor/Tor]: rend_config_services ignores failures in rend_add_service

[Tor Bug Tracker & Wiki]

#20559: rend_config_services ignores failures in rend_add_service
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.1
Parent ID:  #20484| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


Comment:

 428ee66 is now part of bug20484_030_v2

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

Re: [tor-bugs] #19537 [Core Tor/Tor]: Cryptic description for download GETINFO options

[Tor Bug Tracker & Wiki]

#19537: Cryptic description for download GETINFO options
--+
 Reporter:  atagar|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  regression docs spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorS-can
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #9612 [Core Tor/Tor]: Wrong IP used from /etc/hosts

[Tor Bug Tracker & Wiki]

#9612: Wrong IP used from /etc/hosts
--+--
 Reporter:  massar|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * severity:   => Normal


Comment:

 The old answer here is "you didn't set your Address line, so what did you
 expect?"

 I wonder if the new answer should be that we look at the IP address you
 used in your ORPort line, if present, and prefer that guess over the "ask
 for our hostname, then try to resolve it" heuristic.

 (That new answer is newly possible now that ORPorts can have IP addresses
 in them too.)

 That said, am I right that the {{{ORPort 192.0.2.1:443}}} syntax is bad
 news because it (maybe surprisingly) doesn't listen on 0.0.0.0, so e.g. it
 won't listen on localhost? If so I would argue that people who are trying
 to set their Address line by putting an IP address in the ORPort line are
 doing it wrong.

 I guess a much simpler first step could be to notice when the operator
 puts an IP address in ORPort or DirPort, but *doesn't* set their Address
 line, and give them a warning?

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

Re: [tor-bugs] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.9.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression nickm-deferred-20161017  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Seems plausible to me.

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

Re: [tor-bugs] #20560 [Core Tor/Tor]: Some unit tests fail when logging messages on Windows / MinGW64

[Tor Bug Tracker & Wiki]

#20560: Some unit tests fail when logging messages on Windows / MinGW64
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  windows, mingw64, test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 (Merged it as 286fa94064dcc6d1b260bec77de052274e3c4403)

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

Re: [tor-bugs] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.9.3-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  regression nickm-deferred-20161017  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 Thanks; merged 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] #20423 [Core Tor/Tor]: Clock jumps on FreeBSD relay

[Tor Bug Tracker & Wiki]

#20423: Clock jumps on FreeBSD relay
+
 Reporter:  Felixix |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.8.9
 Severity:  Normal  | Resolution:
 Keywords:  regression freebsd  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by s7r):

 I think this is not (always) related to the clock change. I have over 70
 lines of `Nov 08 10:19:49.000 [warn] assign_to_cpuworker failed.
 Ignoring.` , one immediately after another with nothing in between, most
 of them with the very same timestamp, in 3 buckets of :49 (seconds) :50
 (seconds) and :51 (seconds).

 I am on FreeBSD 10.3-RELEASE-p11 with Tor 0.2.9.4-alpha (git-
 8b0755c9bb296ae2).

 I want to add that this relays has been running quite for some time, was
 in 0.2.9.1 and 0.2.8.x as well and is the first time ever it reports this.

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

Re: [tor-bugs] #20085 [Core Tor/Tor]: Tor fails to start if RelayBandwidthRate < 75 KB/s despite torrc stating minimum is 20 KB/s

[Tor Bug Tracker & Wiki]

#20085: Tor fails to start if RelayBandwidthRate < 75 KB/s despite torrc stating
minimum is 20 KB/s
--+
 Reporter:  rchaves   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:  fixed
 Keywords:  docs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Fixed in e4ef9f7491ed1495869692b57644885f9772bef5 (Tor) and
 5300884f74218b51c5a9ac1a7561d642b6d20dc2 (website, faq).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20614 [Applications/Tor Browser]: Add link to Tor Browser manual to about:tor

[Tor Bug Tracker & Wiki]

#20614: Add link to Tor Browser manual to about:tor
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #11698
   Points:|   Reviewer:
  Sponsor:|
--+--
 We can do this for the US English locale now, and for other locales as
 they are produced.

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

Re: [tor-bugs] #12559 [Core Tor/Tor]: DirPort can't fetch router status entries by fingerprint

[Tor Bug Tracker & Wiki]

#12559: DirPort can't fetch router status entries by fingerprint
--+--
 Reporter:  atagar|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * severity:   => Normal


Comment:

 I agree with Nick that serving unsignd subsets of the consensus via the
 dirport is a sketchy idea.

 Something that's using the dirport for this feature could very easily end
 up using it unsafely.

 I would suggest that the better behavior for a program that wants to use
 the dirport for this feature is to fetch the consensus and cache it
 locally, and then when it wants to do a lookup, do an if-modified-since
 dirport request for the consensus, and get and verify the signature and
 cache a new version if there is one, and then use the chunk of the
 consensus that it wanted to use.

 Or is this external application going to want to do just one routerstatus
 lookup?

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:  #20499 =>


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

Re: [tor-bugs] #20535 [Core Tor/Tor]: A 304 "Not Modified" should update the time to when we next expect a modification

[Tor Bug Tracker & Wiki]

#20535: A 304 "Not Modified" should update the time to when we next expect a
modification
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #20499 =>


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

Re: [tor-bugs] #13386 [Core Tor/Tor]: "opening new log file" line goes to err-logfile despite being at loglevel notice (was: [notice] goes to err-logfile)

[Tor Bug Tracker & Wiki]

#13386: "opening new log file" line goes to err-logfile despite being at 
loglevel
notice
--+--
 Reporter:  toralf|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * cc: atagar (added)
 * severity:   => Normal


Comment:

 To be clear, I think it is just that first log entry that goes there,
 since we want to tag the log file with what Tor version we are, and
 generate a line so people can know the log file is working. I think later
 [notice] lines don't end up in the error-level log file.

 Calling that line an [err] doesn't make much sense to me, since errs are
 supposed to be things that prevented the Tor process from continuing.

 And changing the format of log lines, e.g. by not putting a severity on
 this one, will confuse anything that tries to parse the log lines.

 I guess I could see us changing that first line from
 {{{
 Nov 08 20:15:13.065 [notice] Tor 0.3.0.0-alpha-dev (git-25f53955f6d4fd85)
 opening new log file.
 }}}
 to something like
 {{{
 # Opening new log file at Nov 08 20:15:13.065. Tor 0.3.0.0-alpha-dev (git-
 25f53955f6d4fd85).
 }}}

 Damian, you're one of the people who tries to parse lines from the log
 files. What would you want here?

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

Re: [tor-bugs] #15843 [Metrics/Onionoo]: Provide a list of fallback mirrors in case of a server error

[Tor Bug Tracker & Wiki]

#15843: Provide a list of fallback mirrors in case of a server error
-+---
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:2 iwakeh]:
 > I think this could be part of the first release with the solution of
 switching/redirecting to the mirror automatically.
 >
 > Thoughts?

 This is probably blocking on #14201.  And how would an Onionoo instance
 notice that it's supposed to redirect requests to the mirror?

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

Re: [tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * cc: sirmatt@… (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] #20587 [Core Tor/Tor]: Limit next_attempt_overflow to TIME_MAX, not INT_MAX

[Tor Bug Tracker & Wiki]

#20587: Limit next_attempt_overflow to TIME_MAX, not INT_MAX
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  CoreTorTeam201611  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


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

Re: [tor-bugs] #15813 [Metrics/Onionoo]: onionoo instances have distinct contact string encoding

[Tor Bug Tracker & Wiki]

#15813: onionoo instances have distinct contact string encoding
-+---
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by teor):

 We should really standardise on UTF8.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20611 [Core Tor/Tor]: Relays should log a message when they return a 503 error to a client

[Tor Bug Tracker & Wiki]

#20611: Relays should log a message when they return a 503 error to a client
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 A relay operator is concerned that their relay is returning 503 errors,
 but there are no corresponding errors in the logs.

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

Re: [tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => regression
 * milestone:   => Tor: 0.2.9.x-final


Comment:

 We should probably fix this in 0.2.9?

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

Re: [tor-bugs] #20612 [Applications/Tor Browser]: update_responses: Error opening application.ini

[Tor Bug Tracker & Wiki]

#20612: update_responses: Error opening application.ini
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201611R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

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


Comment:

 We have some code checking the two possible paths, and putting the correct
 path in the variable `$appfile`. However we don't use this variable when
 opening the file.

 I attached a patch fixing 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] #20529 [Core Tor/Tor]: Check the directory for each rend service, not just the last one

[Tor Bug Tracker & Wiki]

#20529: Check the directory for each rend service, not just the last one
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:  0.2
Parent ID:  #20484| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #20607 [Core Tor/Chutney]: Revise chutney download schedules for exponential backoff

[Tor Bug Tracker & Wiki]

#20607: Revise chutney download schedules for exponential backoff
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20534| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 We have to be careful with this, because those hard-coded schedules are
 still used for 0.2.8 and earlier in deterministic schedule mode.

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

Re: [tor-bugs] #20511 [Core Tor/Tor]: add a failsafe where if you're about to serve a consensus that you know is obsolete, don't do it

[Tor Bug Tracker & Wiki]

#20511: add a failsafe where if you're about to serve a consensus that you know 
is
obsolete, don't do it
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rubiate):

 > It might be what you wanted here.

 Yes! I did look if there was something to do this, and apparently I should
 have looked harder. Thanks.


 New patch:

 - Parens in define
 - Using rate_limit_log()
 - Log message changed
 - Removed unnecessary NULL assignment

 {{{
 diff --git a/changes/20511 b/changes/20511
 new file mode 100644
 index 000..d6e962e
 --- /dev/null
 +++ b/changes/20511
 @@ -0,0 +1,3 @@
 +  o Minor feature:
 +- Relays and bridges will now refuse to serve the consensus they have
 if
 +  they know it is too old for a client to use. Closes ticket 20511.
 diff --git a/src/or/directory.c b/src/or/directory.c
 index ba6d38c..b5c9d49 100644
 --- a/src/or/directory.c
 +++ b/src/or/directory.c
 @@ -2939,6 +2939,28 @@ handle_get_frontpage(dir_connection_t *conn, const
 get_handler_args_t *args)
return 0;
  }

 +/** Warn that the consensus v of type flavor is too old and
 will
 + * not be served to clients. Rate-limit the warning to avoid logging an
 entry
 + * on every request.
 + */
 +static void
 +warn_consensus_is_too_old(networkstatus_t *v, const char *flavor, time_t
 now)
 +{
 +#define TOO_OLD_WARNING_INTERVAL (60*60)
 +  static ratelim_t warned = RATELIM_INIT(TOO_OLD_WARNING_INTERVAL);
 +  char timestamp[ISO_TIME_LEN+1];
 +  char *dupes;
 +
 +  if ((dupes = rate_limit_log(, now))) {
 +format_local_iso_time(timestamp, v->valid_until);
 +log_warn(LD_DIRSERV, "Our %s%sconsensus is too old, so we will not "
 + "serve it to clients. It was valid until %s local time and
 we "
 + "continued to serve it for up to 24 hours after it
 expired.%s",
 + flavor ? flavor : "", flavor ? " " : "", timestamp, dupes);
 +tor_free(dupes);
 +  }
 +}
 +
  /** Helper function for GET /tor/status-vote/current/consensus
   */
  static int
 @@ -2983,6 +3005,15 @@ handle_get_current_consensus(dir_connection_t
 *conn,

v = networkstatus_get_latest_consensus_by_flavor(flav);

 +  if (v && !networkstatus_consensus_reasonably_live(v, now)) {
 +write_http_status_line(conn, 404, "Consensus is too old");
 +warn_consensus_is_too_old(v, flavor, now);
 +smartlist_free(dir_fps);
 +geoip_note_ns_response(GEOIP_REJECT_NOT_FOUND);
 +tor_free(flavor);
 +goto done;
 +  }
 +
if (v && want_fps &&
!client_likes_consensus(v, want_fps)) {
  write_http_status_line(conn, 404, "Consensus not signed by
 sufficient "
 diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c
 index ed888fb..fde0b18 100644
 --- a/src/or/networkstatus.c
 +++ b/src/or/networkstatus.c
 @@ -1342,6 +1342,24 @@ networkstatus_get_live_consensus,(time_t now))
  return NULL;
  }

 +/** Determine if consensus is valid or expired recently enough
 that
 + * we can still use it.
 + *
 + * Return 1 if the consensus is reasonably live, or 0 if it is too old.
 + */
 +int
 +networkstatus_consensus_reasonably_live(networkstatus_t *consensus,
 time_t now)
 +{
 +#define REASONABLY_LIVE_TIME (24*60*60)
 +  if (BUG(!consensus))
 +return 0;
 +
 +  if (now <= consensus->valid_until + REASONABLY_LIVE_TIME)
 +return 1;
 +
 +  return 0;
 +}
 +
  /*  remove this in favor of get_live_consensus. But actually,
   * leave something like it for bridge users, who need to not totally
   * lose if they spend a while fetching a new consensus. */
 @@ -1350,12 +1368,11 @@ networkstatus_get_live_consensus,(time_t now))
  networkstatus_t *
  networkstatus_get_reasonably_live_consensus(time_t now, int flavor)
  {
 -#define REASONABLY_LIVE_TIME (24*60*60)
networkstatus_t *consensus =
  networkstatus_get_latest_consensus_by_flavor(flavor);
if (consensus &&
consensus->valid_after <= now &&
 -  now <= consensus->valid_until+REASONABLY_LIVE_TIME)
 +  networkstatus_consensus_reasonably_live(consensus, now))
  return consensus;
else
  return NULL;
 diff --git a/src/or/networkstatus.h b/src/or/networkstatus.h
 index 71f36b6..172c0ea 100644
 --- a/src/or/networkstatus.h
 +++ b/src/or/networkstatus.h
 @@ -79,6 +79,8 @@ MOCK_DECL(networkstatus_t
 *,networkstatus_get_latest_consensus,(void));
  MOCK_DECL(networkstatus_t *,networkstatus_get_latest_consensus_by_flavor,
(consensus_flavor_t f));
  MOCK_DECL(networkstatus_t *, 

Re: [tor-bugs] #20613 [Core Tor/Tor]: Silence long-term one-hop circuit diagnostic for single onion intro point circuits

[Tor Bug Tracker & Wiki]

#20613: Silence long-term one-hop circuit diagnostic for single onion intro 
point
circuits
---+---
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, single-onion, tor2web  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * keywords:  tor-hs, single-onion => tor-hs, single-onion, tor2web


Comment:

 (This probably also affects Tor2web's rendezvous point circuits,
 particularly when using Tor2WebRendezvousPoints.)

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

Re: [tor-bugs] #20560 [Core Tor/Tor]: Some unit tests fail when logging messages on Windows / MinGW64

[Tor Bug Tracker & Wiki]

#20560: Some unit tests fail when logging messages on Windows / MinGW64
+
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows, mingw64, test  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by teor):

 The patch seems plausible, but I can't test 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] #20186 [Applications/Tor Browser]: "make update-responses" should extract mar tools

[Tor Bug Tracker & Wiki]

#20186: "make update-responses" should extract mar tools
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201611R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

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


Comment:

 I attached a patch to fix this.

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

Re: [tor-bugs] #20597 [Core Tor/Tor]: Modify test network schedule start times for exponential backoff

[Tor Bug Tracker & Wiki]

#20597: Modify test network schedule start times for exponential backoff
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  CoreTorTeam201611 doc  |  Actual Points:  0.5
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  needs_review => new
 * keywords:
 must-fix-before-0295-alpha, regression, 029-proposed,
 CoreTorTeam201611
 => CoreTorTeam201611 doc
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


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

Re: [tor-bugs] #15798 [Metrics/Onionoo]: details document differences: empty list shown differently

[Tor Bug Tracker & Wiki]

#15798: details document differences: empty list shown differently
-+---
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo 3.1-1.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Replying to [comment:4 iwakeh]:
 > The fix seems fine and should be part of the first release.

 Agreed, pushed to master.

 Also updated the documentation to say "May be omitted if empty."  I
 checked current details files and didn't find a single entry with empty or
 omitted flags list.

 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

[tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 At some point, we started looking at our own address much more often. This
 made the following message appear in the log very often:
 {{{
 router_pick_published_address(): Success: chose address 'x.x.x.x'
 }}}

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

[tor-bugs] #20612 [Applications/Tor Browser]: update_responses: Error opening application.ini

[Tor Bug Tracker & Wiki]

#20612: update_responses: Error opening application.ini
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Since #19528, during the `make update_responses` step we are extracting a
 mar file to read its `application.ini` file. In some cases, when the
 extracted mar file is for OSX, we get an error saying that the
 application.ini file could not be opened.

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

Re: [tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I think we should track down when it got much more commonly called, and
 refactor or cache or whatever so it stops needing to do that.

 For example, we ask ourselves if we know our address when making a
 decision about whether to go to authorities or other caches when fetching
 dir info.

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

Re: [tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 as a kludge, you can just throw in a `tor_assert_nonfatal_unreached()` in
 your local copy of `router_pick_published_address()` and see what the
 stack traces say...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20613 [Core Tor/Tor]: Silence long-term one-hop circuit diagnostic for single onion intro point circuits

[Tor Bug Tracker & Wiki]

#20613: Silence long-term one-hop circuit diagnostic for single onion intro 
point
circuits
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal|   Keywords:  tor-hs, single-onion
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 In #8387, we track long-term single-hop circuits.

 But single onion services deliberately open long-term, one-hop
 introduction point circuits:
 https://trac.torproject.org/projects/tor/ticket/8387?replyto=50#comment:50

 So we should silence this message for single onion service intro point
 circuits.

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

Re: [tor-bugs] #8387 [Core Tor/Tor]: Unbuilt one-hop circuits sometimes hang around forever

[Tor Bug Tracker & Wiki]

#8387: Unbuilt one-hop circuits sometimes hang around forever
-+-
 Reporter:  mikeperry|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, 025-triaged, |  Actual Points:
  027-triaged-1-out 2016-bug-retrospective   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:50 pastly]:
 > I'm getting output related to this ticket every heartbeat it looks like.
 Running 0294-alpha as a single onion service.
 >
 > The real-time up-to-date log is http://bh2lpa5qyawryvk2.onion/log
 >
 > Tor 0.2.9.4-alpha (git-8b0755c9bb296ae2) running on Linux with Libevent
 2.0.10-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
 >
 > Snippit:
 >
 > {{{
 > ...
 > Nov 07 07:50:00.000 [notice] Diagnostic for issue 8387: Found 3 one-hop
 circuits more than 1800 seconds old! Logging 3...
 > Nov 07 07:50:00.000 [notice]   #0 created at 2016-11-06 23:49:39. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 > Nov 07 07:50:00.000 [notice]   #1 created at 2016-11-06 18:23:40. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 > Nov 07 07:50:00.000 [notice]   #2 created at 2016-11-07 05:29:55. open,
 Hidden service: Introduction point. Not marked for close. Package window:
 1000. usable for new conns. Not marked dirty.
 > ...
 > }}}

 There was a time when only directory connections were one-hop, and they
 were expected to finish up quickly.

 With single onion services, the `Hidden service: Introduction point`
 circuits are intentionally long-term, one-hop circuits.

 I've split off this specific issue into #20613.

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

Re: [tor-bugs] #20610 [Core Tor/Tor]: Rate limit router_pick_published_address log message

[Tor Bug Tracker & Wiki]

#20610: Rate limit router_pick_published_address log message
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Knight):

 * cc: Knight (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] #20611 [Core Tor/Tor]: Relays should log a message when they return a 503 error to a client

[Tor Bug Tracker & Wiki]

#20611: Relays should log a message when they return a 503 error to a client
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Knight):

 * cc: Knight (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] #20615 [Core Tor/Tor]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
--+
 Reporter:  bug_bunny |  Owner:  ioerror
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * priority:  Very High => Medium
 * component:  Archived/Torouter => Core Tor/Tor
 * severity:  Critical => Normal
 * milestone:   => Tor: 0.2.9.x-final


Comment:

 Maybe your connection is bad? Maybe your guard is bad?

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

Re: [tor-bugs] #12559 [Core Tor/Tor]: DirPort can't fetch router status entries by fingerprint

[Tor Bug Tracker & Wiki]

#12559: DirPort can't fetch router status entries by fingerprint
--+--
 Reporter:  atagar|  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I wonder if OnionOO is a better data source than the consensus or
 routerstatus for this use 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] #9612 [Core Tor/Tor]: Wrong IP used from /etc/hosts

[Tor Bug Tracker & Wiki]

#9612: Wrong IP used from /etc/hosts
--+--
 Reporter:  massar|  Owner:
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


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

Re: [tor-bugs] #6298 [Core Tor/Tor]: Test 'addr/basic' failure in tor master

[Tor Bug Tracker & Wiki]

#6298: Test 'addr/basic' failure in tor master
--+--
 Reporter:  andrea|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I'm pretty sure we still rely on localhost being present and sane.

 I think I wrote additional tests that rely on localhost being present on
 local interfaces, although our IPv6-only testing probably weeded some of
 them out.

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

Re: [tor-bugs] #7869 [Core Tor/Tor]: ntor-onion-key is padded with an equal sign

[Tor Bug Tracker & Wiki]

#7869: ntor-onion-key is padded with an equal sign
--+--
 Reporter:  rransom   |  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * status:  assigned => new


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

Re: [tor-bugs] #7869 [Core Tor/Tor]: ntor-onion-key is padded with an equal sign

[Tor Bug Tracker & Wiki]

#7869: ntor-onion-key is padded with an equal sign
--+--
 Reporter:  rransom   |  Owner:
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * owner:  nickm =>
 * status:  accepted => assigned
 * severity:   => Normal


Comment:

 Tor 0.2.4.7-alpha is long gone.

 So if somebody wants to do up a patch here, now's a fine time.

 Nick, I'm going to take the liberty of un-owner-ing you on this one.

 It is a good bite-sized ticket for somebody who wants to get involved in
 Tor coding.

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

Re: [tor-bugs] #6298 [Core Tor/Tor]: Test 'addr/basic' failure in tor master

[Tor Bug Tracker & Wiki]

#6298: Test 'addr/basic' failure in tor master
--+--
 Reporter:  andrea|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * severity:   => Normal


Comment:

 Does this bug remain, after all of our unit test work lately?

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

Re: [tor-bugs] #7869 [Core Tor/Tor]: ntor-onion-key is padded with an equal sign

[Tor Bug Tracker & Wiki]

#7869: ntor-onion-key is padded with an equal sign
+--
 Reporter:  rransom |  Owner:
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, easy, intro  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:  tor-relay => tor-relay, easy, intro
 * milestone:  Tor: unspecified => Tor: 0.2.???


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20615 [Archived/Torouter]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
---+--
 Reporter:  bug_bunny  |  Owner:  ioerror
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Archived/Torouter  |Version:  Tor: 0.2.8.9
 Severity:  Critical   |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Hello,
 Its been several weeks, I am experiencing some problems with tor.
 Few weeks ago I started experiencing some connection drops, highly
 inconsistent bandwidth.
 I use to connect my RDP's through tor but connections are dropping
 abruptly after every few minutes, speed is also highly fluctuating, I
 never had this problem before.
 Then I decided to look at ARM, and I been seeing these messages over and
 over again.

 *TIME* [WARN] Your Guard  ($) is failing an extremely large
 amounts of circuits.
 This could indicate a route manipulation attack, extreme network overload
 or a bug. Success counts are ---.
 Use counts are ---. --- cicuits completed. --- were unusable, ---
 collapsed and --- timed out. For referrence,
 your timeout cutoff is 60 seconds.

 *TIME* [WARN] Your Guard - ($) is failing a very large amounts of
 circuits.
 Most likely this means The Tor network is overloaded, but it could also
 mean an attack against you or
 potentially the guard itself. Success counts  etc.

 And

 circuit_package_rely_cell(): Bug: outgoing reply cell sent from
 ../src/or/rely.c:701 has n_chan==NULL.
 Dropping.

 What is this? is this some kind of attack?
 I tried researching about same errors, but with no avail.
 I am using physical isolation technique through virtual environment.
 I was using Tor 0.2.8.9 then I decided to try older versions but still the
 same 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] #9612 [Core Tor/Tor]: Wrong IP used from /etc/hosts

[Tor Bug Tracker & Wiki]

#9612: Wrong IP used from /etc/hosts
--+--
 Reporter:  massar|  Owner:
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 I have not read all the other tickets in detail, but I think you're right,
 this looks like it's now a duplicate ticket. Woo!

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

Re: [tor-bugs] #20615 [Core Tor/Tor]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
--+
 Reporter:  bug_bunny |  Owner:
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


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

Re: [tor-bugs] #20615 [Core Tor/Tor]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
--+
 Reporter:  bug_bunny |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => new


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

Re: [tor-bugs] #20613 [Core Tor/Tor]: Silence long-term one-hop circuit diagnostic for single onion intro point circuits

[Tor Bug Tracker & Wiki]

#20613: Silence long-term one-hop circuit diagnostic for single onion intro 
point
circuits
---+---
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.3-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, single-onion, tor2web  |  Actual Points:  0.2
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * actualpoints:   => 0.2


Comment:

 Please see my bug20613 branch on github.

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

Re: [tor-bugs] #20613 [Core Tor/Tor]: Silence long-term one-hop circuit diagnostic for single onion intro point circuits

[Tor Bug Tracker & Wiki]

#20613: Silence long-term one-hop circuit diagnostic for single onion intro 
point
circuits
---+---
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.3-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, single-onion, tor2web  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * version:  Tor: 0.2.9.1-alpha => Tor: 0.2.9.3-alpha


Comment:

 Replying to [comment:2 arma]:
 > (agreed that 0.2.9 is appropriate, since that's where the single onion
 stuff went in, right?)

 Yes, it was merged in 0.2.9.3-alpha.

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

Re: [tor-bugs] #20613 [Core Tor/Tor]: Silence long-term one-hop circuit diagnostic for single onion intro point circuits

[Tor Bug Tracker & Wiki]

#20613: Silence long-term one-hop circuit diagnostic for single onion intro 
point
circuits
---+---
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, single-onion, tor2web  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 (agreed that 0.2.9 is appropriate, since that's where the single onion
 stuff went in, right?)

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

Re: [tor-bugs] #20615 [Core Tor/Tor]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
--+
 Reporter:  bug_bunny |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 One of the big first questions is: are *you* the one overloading your
 guard, with the traffic you're producing?

 Can you tell us more about this phrase "connect my RDP's through tor"?

 What sort of traffic, and circuits, is your Tor client putting out?

 In particular, since you're not using your Tor client in a standard
 configuration: what sort of stream isolation is your Tor client set up to
 do?

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

Re: [tor-bugs] #20118 [Applications/Tor bundles/installation]: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser

[Tor Bug Tracker & Wiki]

#20118: Don't unpack HTTPS Everywhere anymore while bundling Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability, GeorgKoppen201609,|  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 That got picked up for 6.0.6 with commit
 b373d46c616682000ff07029eaa4a113e29b286e on maint-6.0.

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